ejemplo arqsw

Universidad de Los Andes

Aplicacin Intermediaria ArqSw

Documento de Arquitectura del Sistema Aplicacin Intermediaria ArqSw

Nombre del Equipo de Trabajo: Ovalle Solutions

Nombre de los Integrantes:

Andrs Felipe Ovalle Crdenas e-mail: [email protected]

Bogot D.C. 2008

Universidad de Los Andes - Arquitectura de Software 2008-1

Versin

5.0 Modificado Por

Andrs Felipe

Ovalle Crdenas

Fecha

29 de Julio de 2008

Comentarios

Entrega final del proyecto de la Aplicacin Intermediaria ArqSw

Universidad de Los Andes Arquitectura de Software 2008-2

last saved: viernes, agosto 22, 2008 i

Tabla de Contenido

1 Contexto ............................................................................................................ 5

1.1 Problemas a Resolver ....................................................................... 5

1.1.1Descripcin General del Sistema a Desarrollar .......................................... 5

1.1.2Objetivos..................................................................................................... 6

1.2 Fundamento de la Solucin.............................................................. 6

1.2.1Aproximaciones Arquitecturales ................................................................. 7

1.2.2Cubrimiento de Requerimientos ................................................................. 8

2 Stakeholders ................................................................................................... 12

3 Atributos de Calidad....................................................................................... 16

3.1 Perspectivas .................................................................................... 16

3.1.1Evolucin .................................................................................................. 16

3.2 Escenarios de Calidad .................................................................... 18

3.3 Escenario de Modificabilidad ......................................................... 18

3.4 Escenario de Disponibilidad .......................................................... 19

3.5 Escenario de Concurrencia ............................................................ 20

4 Puntos de Vista ............................................................................................... 21

4.1 Punto de Vista de Despliegue ........................................................ 21

4.1.1Descripcin ............................................................................................... 21

4.1.2Modelo de Plataforma de Ejecucin ......................................................... 22

4.1.3Modelo de Red ......................................................................................... 24

4.1.4Modelo de Dependencia Tecnolgica ....................................................... 26

4.2 Punto de Vista Funcional................................................................ 28

4.2.1Descripcin ............................................................................................... 28


ii last saved: viernes, agosto 22, 2008

4.2.2Procesos de Negocio Principales en ArqSw .............................................28

4.2.3Modelos de Estructura Funcional ..............................................................30

4.3 Punto de Vista de Informacin........................................................37

4.3.1Descripcin................................................................................................37

4.3.2Modelo de Estructuras Estticas de Datos................................................37

4.3.3Modelos de Ciclo de Vida de Informacin .................................................40

4.3.4Modelo de Propiedad de Datos .................................................................44

4.3.5Modelos de Flujo de Informacin ..............................................................45

5 Evaluacin de la Arquitectura ........................................................................46

5.1 rbol de Atributos de Calidad.........................................................46

6 Referencias ......................................................................................................47

7 Directorio..........................................................................................................48

7.1 ndice .................................................................................................48

7.2 Glosario de Trminos ......................................................................48

7.3 Acrnimos.........................................................................................48


ltima Fecha de Actualizacin: viernes, agosto 22, 2008 1

Lista de Figuras

Figura 1: Aplicacin Intermediaria ArqSw: Casos de Uso Principales ........ 8

Figura 2: Aplicacin Intermediaria ArqSw: Runtime and Networking Model22

Figura 4: Aplicacin Intermediaria ArqSw: Proceso de Realizacin de Pedidos 29

Figura 5: Aplicacin Intermediaria ArqSw: Modelo Conceptual ................. 30

Figura 6: Aplicacin Intermediaria ArqSw: Diagrama de Composicin y Agregacin para el componente de Productos ........................................... 33

Figura 7: Aplicacin Intermediaria ArqSw: Diagrama de Composicin y Agregacin para el componente de Usuarios.............................................. 34

Figura 8: Aplicacin Intermediaria ArqSw: Diagrama de Composicin y Agregacin para el componente de Pedidos ............................................... 35

Figura 9: Aplicacin Intermediaria ArqSw: Modelo de Componentes e Interfaces ......................................................................................................... 36

Figura 10: Aplicacin Intermediaria ArqSw: Modelo General de Estructuras Estticas de Datos .......................................................................................... 38

Figura 11: Aplicacin Intermediaria ArqSw: Modelo Detallado de Estructuras Estticas de Datos .......................................................................................... 39

Figura 12: Aplicacin Intermediaria ArqSw: Modelo de Ciclo de Vida de Informacin de Producto ............................................................................... 40

Figura 13: Aplicacin Intermediaria ArqSw: Modelo de Ciclo de Vida de Informacin de una Categora ....................................................................... 41

Figura 14: Aplicacin Intermediaria ArqSw: Modelo de Ciclo de Vida de Informacin de un Pedido.............................................................................. 42


2 ltima fecha de actualizacin: viernes, agosto 22, 2008

Figura 15: Aplicacin Intermediaria ArqSw: Modelo de Ciclo de Vida de Informacin del Carrito de Compras .............................................................43

Figura 16: Aplicacin Intermediaria ArqSw: Modelo de Ciclo de Vida de Informacin de un Proveedor.........................................................................43

Figura 17: Aplicacin Intermediaria ArqSw: Modelo de Ciclo de Vida de Informacin de un Cliente...............................................................................44

Figura 17: Aplicacin Intermediaria ArqSw: Modelo de Flujo de Informacin45

Figura 18: Aplicacin Intermediaria ArqSw: rbol de Atributos de Calidad 46



Lista de Tablas

Tabla 1: Actores contemplados para la Aplicacin Intermediaria ArqSw .. 8

Tabla 2: Casos de Uso contemplados para la Aplicacin Intermediaria ArqSw 9

Tabla 3: Listado de los Stakeholders para la Aplicacin Intermediaria ArqSw 12

Tabla 4: Stakeholders y Concerns para la Aplicacin Intermediaria ArqSw13

Tabla 5: Stakeholders y Viewpoints para la Aplicacin Intermediaria ArqSw 15

Tabla 6: Nodos identificados para el Runtime Model de la Aplicacin Intermediaria ArqSw ....................................................................................... 22

Tabla 7: Caractersticas de red en el Networking Model de la Aplicacin Intermediaria ArqSw ....................................................................................... 25

Tabla 8: Modelo de Dependencia Tecnolgica Aplicacin Intermediaria ArqSw 26

Tabla 9: Elementos Arquitecturales Identificados para la Aplicacin Intermediaria ArqSw ....................................................................................... 31

Tabla 10: Asociaciones entre Elementos Identificados para la Aplicacin Intermediaria ArqSw ....................................................................................... 31

Tabla 11: Asociaciones entre Entidades de Informacin para la Aplicacin Intermediaria ArqSw ....................................................................................... 38

Tabla 12: Modelo de Propiedad de Datos para la Aplicacin Intermediaria ArqSw 45



1 Contexto

1.1 Problemas a Resolver Desde una perspectiva global, el problema principal es desarrollar una aplicacin que facilite los procesos de intermediacin entre el comprador y un proveedor, con respecto a la demanda de una serie de productos que son ofrecidos por este ltimo.

De esta manera, el problema se divide en los siguientes subproblemas, cuyas soluciones se implementan a travs de la arquitectura del sistema propuesta.

1. Es necesario que los clientes puedan consultar una serie de productos, por medio de diferentes tipos de consultas de forma tal, que pueda encontrar fcilmente aquellos que demande su actividad comercial. Es as que debe aclararse

2. Los clientes deben poder acumular en una lista, el conjunto de productos, con su informacin inherente y cantidades especficas, a lo largo de la sesin que establezca con el sistema de intermediacin. De esta manera, tan pronto el cliente finalice su interaccin con el sistema, se debe impedir que otro usuario revise las peticiones y preferencias del anterior cliente.

3. Finalmente, el cliente debe poder interactuar con el sistema de forma tal, que pueda modificar las cantidades solicitadas de un producto, agregar otros productos y eliminar peticiones que haya realizado con anterioridad.

1.1.1 Descripcin General del Sistema a Desarrollar Teniendo en mente lo anterior, se propone la construccin de una aplicacin de intermediacin para ArqSw que permita la satisfaccin de las necesidades anteriormente planteadas. De esta manera, dicha propuesta contempla el desarrollo de un sistema de software distribuido, cuya interaccin con los usuarios finales se realizar por medio de un ambiente Web, soportado por una capa de lgica de negocios y otra de persistencia de los datos inherentes a los productos y clientes manejados por la empresa.



1.1.2 Objetivos A continuacin se presentan los objetivos generales que guan el desarrollo de la arquitectura propuesta, para la construccin de la aplicacin intermediaria para ArqSw.

1. Ofrecer una percepcin del sistema a implementar, desde diferentes puntos de vista, con el propsito de lograr la satisfaccin de las necesidades planteadas por los stakeholders identificados en ArqSw.

2. Proponer diferentes arquitecturas candidatas que ofrezcan la flexibilidad necesaria, frente a los requerimientos funcionales manifestados por los stakeholders y los requerimientos no funcionales identificados durante la fase de levantamiento de informacin y a lo largo del desarrollo de la arquitectura y su concertacin.

3. Desarrollar una herramienta de comunicacin para la definicin clara de necesidades e identificacin adecuada de caminos de solucin por medio del diseo arquitectural realizado, logrando adicionalmente una optimizacin tanto de los recursos humanos como financieros, que intervienen en la implementacin de la arquitectura elegida.

1.2 Fundamento de la Solucin A travs de la presente arquitectura de software y el sistema que se describe por medio de los diferentes puntos de vista desarrollados, pensamos que se pueden satisfacer de forma adecuada los requerimientos funcionales identificados, para la construccin de la Aplicacin Intermediaria de ArqSw.

Sin embargo, lo ms importante de la arquitectura de software que se propone para el sistema en cuestin, es el hecho de que esta satisface los requerimientos no funcionales que se han descubierto despus de un proceso arduo de recoleccin de informacin y concertacin con los stakeholders de la compaa comercial ArqSw.

En ese orden de ideas, los requerimientos funcionales identificados pueden apreciarse desde la seccin de problemas y los requerimientos no funcionales descubiertos, comprenden una alta disponibilidad del sistema de intermediacin y tiempos de respuesta rpidos en los servicios de consulta implementados.



1.2.1 Aproximaciones Arquitecturales Como se manifest anteriormente, la presente arquitectura es descrita a travs de los puntos de vista desarrollados y es as que por medio de cada uno de estos se posibilita la visualizacin de cmo los requerimientos funcionales y no funcionales son satisfechos por los diseos arquitecturales propuestos.

De esta manera, es necesario comenzar por mostrar el deployment viewpoint, en el cual se presenta la infraestructura tecnolgica que permitir la ejecucin de la solucin de software a implementar y adicionalmente, se muestran algunos de los requerimientos tanto en hardware como en software, indispensables para la implantacin del sistema de intermediacin ArqSw. Adicionalmente es importante destacar que a travs de este punto de vista, se puede observar como es posible satisfacer el requerimiento no funcional de alta disponibilidad del sistema, por medio de la conformacin de clster de los servidores de aplicaciones, de los servidores web y de los servidores de bases de datos; ofreciendo un servicio de respaldo en caso de fallas en alguno de estos equipos y de manera adicional, logrando un servicio de balanceo de carga; teniendo en cuenta la alta concurrencia a la que ser sometido la Aplicacin Intermediaria.

Posteriormente, se realizar una descripcin del sistema desde el punto de vista funcional, siendo este en el cual se tomaron las mayores decisiones arquitecturales, dado que los modelos que conforman este viewpoint influyen en una gran media en la modularidad, flexibilidad y la estructura de servicios que se pretende ofrecer al implementar el sistema de intermediacin comercial.

Por ltimo, se describir por medio del information viewpoint, las entidades informacionales en la que se realizar el almacenamiento y gestin de la informacin de la aplicacin de intermediacin comercial, describiendo sus ciclos de vida y flujos a travs del sistema. De esta manera, es necesario hacer nfasis en que dado el diseo de componentes e interfaces del punto de vista funcional, se determin utilizar un conjunto de unidades informacionales de acuerdo a la especialidad de los componentes desarrollados anteriormente. Es as, que an ms desde este ltimo punto de vista se puede evidenciar la gran cohesin que existe dentro de los componentes diseados como subsistemas de la aplicacin de intermediacin de ArqSw, buscando mecanismos directos de comunicacin en aras de lograr un mejor rendimiento en los recursos utilizados para el funcionamiento global del sistema.



1.2.2 Cubrimiento de Requerimientos Inicialmente se cuenta con el siguiente use case view, construido a partir del contexto y los concerns identificados con la ayuda de los stakeholders.

Figura 1: Aplicacin Intermediaria ArqSw: Casos de Uso Principales Teniendo en cuenta el anterior diagrama, es posible visualizar a los actores y a los casos de uso inicialmente contemplados, para el desarrollo arquitectural propuesto; y en ese orden de ideas los elementos anteriormente mostrados son descritos en detalle a continuacin. Tabla 1: Actores contemplados para la Aplicacin Intermediaria ArqSw

Actor Descripcin

Gerente Comercial Representa a la persona o conjunto de personas, encargados de

la administracin del sistema de forma global, quienes definen



Actor Descripcin

el manejo y ciclo de vida de los clientes, proveedores,

productos, categoras o usuarios del sistema en cuestin.

Cliente Representa a la persona que solicita una serie de productos en

determinadas cantidades de acuerdo a la oferta disponible, por

medio del sistema de intermediacin comercial.

Proveedor Representa a las entidades encargadas de ofrecer el suministro

de productos, de acuerdo a las categoras comerciales

disponibles en el sistema de intermediacin comercial.

Usuario Simboliza una generalizacin de los proveedores, clientes y

gerentes comerciales, a travs de la cual se comparte una serie

de casos de uso que representan la administracin del ciclo de

vida de todos los tipos de usuarios del sistema de

intermediacin.

Tabla 2: Casos de Uso contemplados para la Aplicacin Intermediaria ArqSw

Caso de Uso Descripcin

Ingresar al sistema Procedimiento mediante el cual, un usuario es validad para

poder utilizar los servicios correspondientes a su rol, en el

sistema de intermediacin comercial.

Buscar productos Representa el procedimiento por medio del cual, un cliente o el

gerente comercial de ArqSw, puede consultar los productos

disponibles en el sistema.

Registrar producto Caso de uso que define, las actividades necesarias para el

registro de un producto y su informacin inherente dentro del

sistema.

Modificar producto Procedimiento a travs del cual se posibilita la modificacin de

la informacin relacionada con un producto, disponible en el

sistema.

Deshabilitar producto Procedimiento por medio del cual, es posible bloquear un

producto y su informacin correspondiente, de forma tal que




los clientes no puedan hacer peticiones, ni los proveedores

puedan suministrar ninguna cantidad sobre el mismo.

Realizar pedido Procedimiento que define una conjunto de actividades, para la

realizacin de un pedido por parte de un cliente, con relacin a

un producto especfico y una cantidad de los mismos, de

acuerdo a la disponibilidad de estos en el sistema.

Modificar pedido Caso de uso que define una serie de actividades para la

modificacin de la informacin relacionada a un pedido, que

solo puede ser implementado por el mismo cliente o por el

gerente comercial de ArqSw.

Eliminar pedido Procedimiento por medio del cual un cliente o el gerente

comercial pueden eliminar un pedido especfico, a travs del


Listar pedidos Conjunto de actividades por medio de las cuales es posible

listar todos los pedidos, realizados por un cliente especfico con

relacin a unos productos y una cantidades determinadas.

Registrar categora Procedimiento mediante el cual es posible, ingresar una nueva

categora de productos al sistema y su informacin

correspondiente, por parte del gerente comercial de ArqSw.

Modificar categora Procedimiento mediante el cual se realizan cambios sobre la

informacin correspondiente a una categora de productos

especfica, dentro del sistema de intermediacin comercial de

ArqSw.

Consultar categora Procedimiento de bsqueda a travs del cual se puede consultar

una categora especfica de producto dentro del sistema.

Deshabilitar categora Procedimiento que permite el bloqueo de una categora de

producto, impidiendo realizar registros, consultas y/o pedidos

de productos relacionados con la misma.

Registrar usuario Caso de uso que representa el conjunto de actividades

necesarias para la inclusin de un cliente, proveedor o gerente

comercial dentro del sistema, concedindole la posibilidad de




utilizar los servicios ofrecidos por el mismo.

Modificar usuario Procedimiento que posibilita el cambio de la informacin

relacionada con un cliente, proveedor o gerente comercial

dentro del sistema de intermediacin.

Consultar usuario Procedimiento que permite la bsqueda de un usuario, ya sea

cliente, proveedor o gerente comercial, a travs de diferentes

criterios.

Inhabilitar usuario Procedimiento mediante el cual, un usuario determinado de

cualquier tipo, puede ser bloqueado en el sistema, de forma

talque no pueda hacer uso alguno de los recursos, disponibles

en el sistema con relacin al rol con respecto al cual ha sido

creado.

Se requiere aclarar que los anteriores casos de uso y actores identificados, influyen de manera directa con el desarrollo del functional viewpoint, el cual es indispensable para la implementacin de los procesos y procedimientos en los cuales intervienen los usuarios finales de la implementacin del sistema.



2 Stakeholders

Esta seccin presenta una lista de los stakeholders involucrados en el proyecto. Para cada uno de ellos, se deben listar los concerns que van a ser tenidos en cuenta en el documento de arquitectura. Esta informacin se presenta en forma de matriz, donde las filas representan los stakeholders y las columnas los concerns. Cada celda determina el grado de relevancia del concern para el stakeholder. Finalmente, basados en los concerns relevantes a cada stakeholder se determinan los puntos de vista que se le presentarn.

El standard ANSI/IEEE 1471-2000 propone que al menos los siguientes stakeholders sean considerados: usuarios, clientes, desarrolladores y administradores.

Customer Application software developers Infrastructure software

developers End users

Application system engineers Application hardware engineers

Project manager Communications engineers Chief Engineer/Chief Scientist

Program management System and software integration

and test engineers Safety engineers and certifiers

External organizations Operational system managers Trainers

Maintainers Auditors Security engineers and certifiers

Tabla 3: Listado de los Stakeholders para la Aplicacin Intermediaria ArqSw

Stakeholder Descripcin

Gerente Comercial Es el encargado de administrar el funcionamiento de los

departamentos de ArqSw, en conjunto con los recursos que

estos emplean para su funcionamiento; de acuerdo, a la

planeacin estratgica que desarrolle, para continuar el

cumplimiento de la misin organizacional. Tambin es el

encargado de definir los productos a ofrecer con sus respectivas

categoras, al igual que decide que proveedores y empleados

pueden trabajar con ArqSw.

Cliente Son todas las personas, que hacen uso de los servicios

prestados por ArqSw, solicitando productos de diferentes tipos,

en ciertas cantidades de acuerdo a la oferta propuesta por esta

organizacin comercial.

Proveedor Se refiere a la persona encargada de suministrar los productos

que oferta la organizacin comercial ArqSw de acuerdo a las

categoras de producto que esta determine.

Director de Sistemas El director de sistemas es el funcionario responsable del

funcionamiento de las tecnologas de la informacin y de las

comunicaciones de la compaa, que permiten la ejecucin de

las diferentes labores que desarrollan los empleados de ArqSw.



Stakeholder Descripcin

Tambin es la persona encargada de coordinar las labores de

configuracin, mantenimiento y supervisin del hardware,

software y de las redes de comunicaciones de ArqSw.

Application Software Developers Representa al grupo de personas encargadas del desarrollo,

mantenimiento y actualizacin de la aplicacin intermediaria

que se propone por medio de la arquitectura presentada.

Application Hardware Engineers Se refiere al personal especialista en la puesta en marcha,

configuracin, supervisin y mantenimiento de los servidores,

dispositivos de interconexin, equipos de cmputo, etc., que

maneja ArqSw como TICs, siendo estas las herramientas para

la ejecucin de sus labores.

Communications Engineers Es el grupo de personas encargado de la configuracin,

supervisin y mantenimiento de las redes de comunicaciones

que maneja ArqSw para la transmisin de informacin.

Trainers Es el personal encargado, de brindar la orientacin y formacin

suficiente a los empleados de ArqSw, para el manejo del

Hardware, Software y TICs en general, que se tienen como

herramientas en esta compaa comercial.

Tabla 4: Stakeholders y Concerns para la Aplicacin Intermediaria ArqSw

Stakeholder Concerns

Gerente Comercial 1. Administrar los productos ofrecidos por ArqSw, a travs del sistema de

intermediacin comercial.

2. Definir las categoras de los productos a ofertar por medio de la

aplicacin intermediaria.

3. Validar a la entrada de los proveedores al sistema, registrando su

informacin de contacto y permitiendo al igual el registro de sus productos en

las cantidades que estos determinen.

4. Administrar el ciclo de vida de los clientes y empleados de la compaa

comercial, a travs del sistema de intermediacin.

5. Implementar consultas de productos, categoras y usuarios en general, a



Stakeholder Concerns

travs de diferentes criterios.

Cliente 1. Ingresar de forma rpida y fcil en el sistema de intermediacin, con el

fin de utilizar los servicios ofrecidos por la aplicacin.

2. Realizar consultas de productos a travs de diferentes criterios.

3. Hacer pedidos de productos registrados en la aplicacin en ciertas

cantidades, de acuerdo a las existencias disponibles en el inventario.

4. Usar un sistema de carrito de compras virtual, por medio del cual sea

posible agregar, modificar o eliminar pedidos de productos con las

respectivas cantidades solicitadas.

Proveedor 1. Ingresar en el sistema, de forma tal que sistema de intermediacin oferte

los productos que sean suministrados, teniendo en cuenta el nmero de

unidades del producto configuradas.

2. Ingresar, modificar o deshabilitar, los productos que sean suministrados

para su oferta en la aplicacin intermediaria.

Director de Sistemas 1. Ofrecer mecanismos de consulta concurrente, alta disponibilidad y

tiempos de respuesta rpidos.

2. Desarrollar el sistema de intermediacin comercial, a travs de una

interfaz WEB.

Application Software Developers 1. Conocer la arquitectura de software, tecnologas, componentes y tiempo

requeridos para el desarrollo del software de intermediacin comercial para

ArqSw.

Application Hardware Engineers 1. Conocer los requerimientos tcnicos del software que ser utilizado y

caractersticas del hardware presente en ArqSw.

Communications Engineers 1. Conocer los requerimientos de red impuestos por el software de

intermediacin que ser implementado en la compaa.

Trainers 1. Conocer el funcionamiento de la aplicacin intermediaria, con el fin de

brindar el entrenamiento o capacitacin adecuada a los usuarios del sistema.



Tabla 5: Stakeholders y Viewpoints para la Aplicacin Intermediaria ArqSw

Stakeholder Viewpoints

Gerente Comercial Operational viewpoint, Deployment viewpoint.

Cliente Operational viewpoint.

Proveedor Operational viewpoint.

Director de Sistemas Concurrency viewpoint, Deployment viewpoint, Functional viewpoint e

Information viewpoint.

Application Software Developers Functional viewpoint, Information viewpoint, Concurrency viewpoint,

Development viewpoint y Deployment viewpoint.

Application Hardware Engineers Information viewpoint, Concurrency viewpoint y Deployment viewpoint.

Communications Engineers Information viewpoint, Concurrency viewpoint y Deployment viewpoint.

Trainers Functional viewpoint y Operational viewpoint.



3 Atributos de Calidad

3.1 Perspectivas Esta seccin describe el comportamiento y los atributos de calidad de los requerimientos que afectan la arquitectura de software, incluidos escenarios de calidad.

3.1.1 Evolucin Teniendo en cuenta la presente arquitectura y los requerimientos no funcionales planteados por los stakeholders, es posible garantizar la capacidad de evolucin del sistema, considerando el diseo funcional propuesto. De esta manera, se presentar con un mayor nivel de detalle, como la arquitectura elegida exhibe de una forma adecuada el cumplimiento de este atributo de calidad, as.

3.1.1.1 Calidad Deseada La arquitectura de software desarrollada, ofrece una flexibilidad adecuada frente a la adicin y/o reemplazo de componentes funcionales del sistema. Sin embargo, en caso de modificar y/o reemplazar un componente determinado, es necesario que estas alteraciones respeten las interfaces requeridas al igual que los servicios que ofrecen.

3.1.1.2 Aplicabilidad Teniendo en mente lo anterior, es posible decir que esta perspectiva afecta de manera transversal al punto de vista funcional y en igual magnitud, al punto de vista de informacin, dado que esta flexibilidad del sistema frente al cambio, solo puede ser lograda a travs de la estructura de componentes ofrecida, los servicios manejados por medio de las interfaces diseadas, la estructura esttica de datos presentada, los estados definidos para las unidades informacionales y los flujos de datos identificados entre componentes. Sin embargo, con lo anterior no se est afirmando, que esta perspectiva no afecte otros puntos de vista; sino que su influencia es mayor en los viewpoint contemplados.

3.1.1.3 Concerns Especficamente, se espera que la arquitectura no se vea comprometida de manera crtica, al inducir un cambio en su estructura de componentes y por ende, es su estructura de unidades informacionales.

3.1.1.4 Actividades

Las actividades para aplicar esta perspectiva de evolucin a los puntos de vista funcional y de informacin, son los siguientes.



Identificar claramente los cambios a inducir en el sistema, para la evolucin deseada.

Evaluar la flexibilidad actual del sistema frente al tipo de cambios identificados. Adicionalmente, analizar el impacto en para el caso de modificacin, reemplazo y/o eliminacin de componentes desde el functional viewpoint y las consecuencias de estas alteraciones, en las estructuras de datos, estados y flujos de informacin.

Plantear los tradeoff posibles frente a los cambios identificados y su impacto en los puntos de vista funcional y de informacin.

Finalmente, implementar los cambios arquitecturales a los que haya lugar, teniendo en cuenta las consideraciones y resultados, obtenidos por medio de esta perspectiva de evolucin.

3.1.1.5 Tcticas Las aproximaciones y precisiones necesarias para el cumplimiento del atributo de modificabilidad, comprenden bsicamente la conservacin del esquema de servicios que se tiene a travs de las interfaces diseadas, la agrupacin de los elementos arquitecturales por su grado de especializacin, frente a las reglas del negocio identificadas en ArqSw.



3.2 Escenarios de Calidad Esta seccin presenta los diferentes escenarios de calidad utilizados para modelar el los estmulos y las respuestas esperadas por el sistema una vez en ejecucin y que han sido tenidos en cuenta durante la definicin de la arquitectura.

3.3 Escenario de Modificabilidad

3.3.1.1 Descripcin Se desea adicionar un campo a la informacin de un producto, de forma tal que las alteraciones en la capa WEB, en la lgica de negocio, en la capa de persistencia y en las estructuras de datos, se implementen en menos de 50 minutos, impactando el mnimo nmero de componentes funcionales y entidades informacionales.

3.3.1.2 Fuente Producto.

3.3.1.3 Estimulo Agregar un campo a la informacin de un producto.

3.3.1.4 Artefacto Las entidades del sistema, los session bean, los entity bean y la capa WEB.

3.3.1.5 Ambiente Se tiene un ambiente de desarrollo (eclipse) con el proyecto creado y listo para hacer deployment. Ya fue probado el deployment del componente antes del cambio.

3.3.1.6 Respuesta Los desarrolladores logran hacer el cambio y hacer deployment sin errores, las tablas de la base de datos son actualizadas para las nuevas entidades al hacer deployment y la interfaz grfica permite crear los clientes con el nuevo campo.

3.3.1.7 Medida de la Respuesta El cambio y su despliegue en JBoss toma menos de 50 minutos.



3.4 Escenario de Disponibilidad

3.4.1.1 Descripcin Durante una fase de consulta de informacin concurrente, por parte de los clientes de ArqSw, el servidor de aplicaciones de esta rea sufre una falla en el suministro elctrico y por ende, no puede responder a las peticiones de informacin que se le estn haciendo desde los browsers de los mismos clientes. Se requiere, que el sistema de intermediacin comercial vuelva a responder al 95% de las peticiones en un periodo inferior a 5 minutos, utilizando el servicio de backup del clster de servidores de clientes y redistribuyendo la carga transaccional del servidor de aplicaciones principal a los dems servidores funcionales.

3.4.1.2 Fuente

Clientes.

3.4.1.3 Estimulo Consulta de productos y realizacin de pedidos.

3.4.1.4 Artefacto Main Customer Application Server.

3.4.1.5 Ambiente Se da el estmulo en un ambiente de ejecucin normal, en un contenedor de aplicaciones JBoss, que ha venido funcionando sin inconvenientes.

3.4.1.6 Respuesta Volver a responder a dichas peticiones, utilizando el servicio de backup del clster de servidores de clientes y redistribuyendo la carga transaccional del servidor de aplicaciones principal a los dems servidores funcionales.

3.4.1.7 Medida de la Respuesta Este sistema de backup y de balanceo de carga debe entrar a responder el 95% de las peticiones no resueltas por parte de los browsers de los clientes, en un periodo inferior a 5 minutos.



3.5 Escenario de Concurrencia

3.5.1.1 Descripcin Durante un periodo de ejecucin normal del sistema de la aplicacin intermediaria, se realiza un procesamiento concurrente de registro de productos, inducido por los proveedores de ArqSw con respecto a un conjunto de productos, en distintas categoras y cantidades de los mismos. Es necesario, que los proveedores puedan utilizar la funcionalidad requerida por parte del componente de productos y el componente de proveedores, visualizando sus respectivas interfaces de registro de productos, con tiempos de respuesta inferiores a 5 segundos para una concurrencia de 200 proveedores, aprovechando el servicio de balanceo de carga que se ofrece en el clster de servidores para proveedores.

3.5.1.2 Fuente Proveedores.

3.5.1.3 Estimulo Registro concurrente de productos.

3.5.1.4 Artefacto Componente de productos, componente de proveedores y Supplier Application Server.

3.5.1.5 Ambiente Ambiente de ejecucin normal de la aplicacin intermediaria, con un promedio aproximado de 200 proveedores accediendo concurrentemente al servidor de aplicaciones para proveedores.

3.5.1.6 Respuesta y Medida de la Respuesta Se espera que se redistribuya la carga transaccional entre la totalidad de los servidores para proveedores, permitiendo ofrecer una concurrencia de 200 proveedores, con tiempos de respuesta en los browsers inferiores a 5 segundos, aprovechando el servicio de balanceo de carga que existe en este clster de servidores.



4 Puntos de Vista

Teniendo en cuenta los concerns identificados en cada uno de los stakeholders, se proponen los siguientes puntos de vista, con el fin de comunicar y describir como sus necesidades sern satisfechas a travs de la arquitectura que se propone.

4.1 Punto de Vista de Despliegue Despus de haber hecho el levantamiento de informacin en la compaa comercial ArqSw, se lleg a la siguiente vista de despliegue en la que se compone el runtime model y el networking model a travs de un solo diagrama, por medio del cual se describir el ambiente que recibir la implementacin de la arquitectura de software presentada, incluyendo las dependencias tecnolgicas de la plataforma de ejecucin. Por otro lado, este punto de vista tambin mostrar la correspondencia entre los elementos de software requeridos y su ambiente de ejecucin.

4.1.1 Descripcin A travs de los siguientes modelos de plataforma de ejecucin, red y de dependencias tecnolgicas, es posible observar que la propuesta arquitectural pretende utilizar un servidor de aplicaciones corporativo, encargado de centralizar la funcionalidad de la aplicacin intermediaria; permitiendo la sincronizacin de los servicios de almacenamiento, la presentacin de la informacin a travs de un ambiente WEB; distribuyendo los servicios prestados por el sistema de intermediacin comercial entre los Customer Application Server y Supplier Application Server de la compaa. De igual forma es posible, observar que el Server Core est conformado, por los WEB Server, Corporate Application Server, Database Server, Customer Application Server y Supplier Application Server; de manera tal, que esta regin del sistema est siendo protegida a travs de un sistema de Firewall que regulan las conexiones establecidas por parte de usuarios externos como clientes y proveedores de ArqSw.



4.1.2 Modelo de Plataforma de Ejecucin

Figura 2: Aplicacin Intermediaria ArqSw: Runtime and Networking Model Como se puede apreciar en la figura 2, cada parte del server core maneja un sistema de clster o granjas de servidores, con el fin de ofrecer un mecanismo de balanceo de cargas, permitindole a los servicios ofrecidos soportar una alta concurrencia de conexiones, provenientes de los usuarios del sistema de intermediacin comercial. As mismo, a travs de esta infraestructura de granjas de servidores se conforma un sistemas de backup, en los cuales si un servidor deja de funcionar, las conexiones son redireccionadas y redistribuidas sobre los dems servidores funcionales del sistema. A continuacin se describir el funcionamiento de cada uno de los nodos presentes en el diagrama anteriormente mostrado. Tabla 6: Nodos identificados para el Runtime Model de la Aplicacin Intermediaria

ArqSw

Nodo Descripcin Caractersticas

Customer,

Supplier and

ArqSw machine.

Este nodo representa una mquina externa a ArqSw con las

caractersticas mnimas, que permiten interactuar con la

aplicacin intermediaria, por medio de un WEB browser.

OS: Microsoft Windows XP

Memory: 256 MB or greater

CPU: 1.2 GHz

Manufacter: Intel or AMD




Firewall 1 Este dispositivo representa a los cortafuegos que regulan y

vigilan las conexiones entrantes al WEB server de ArqSw.

Model: ZyXEL ZyWALL 70

Manufacter: ZyWALL

WEB server Este nodo representa la mquina en la que se tiene instalado el

WEB server, en una organizacin de clster con el fin de

realizar un balanceo de cargas de las conexiones entrantes y un

conformar un sistema de respaldo para el acceso externo al


OS: Microsoft Windows Server

2003 R2 SP2

Memory: 128 GB

CPU: 4 CPU Quad Core Xeon

7300 Series, 1066 MHz

Manufacter: Intel

Clustered

Corporate

application server

Este nodo representa al servidor de aplicaciones corporativo en

donde est el core de la aplicacin y a travs del cual se

distribuyen los servicios prestados por el componente de

usuarios (clientes, proveedores, administradores, etc.) a los

dems servidores de aplicaciones de la compaa. De esta

manera, se puede proporcionar escalabilidad al sistema por

medio de este nodo.

Por otro lado, este nodo representa una granja de servidores

que ofrece un sistema de balanceo de carga y tambin un

sistema de respaldo orientado a permitir una alta tolerancia a

cadas del sistema.


2003 R2 SP2

Memory: 128 GB



Manufacter: Intel

Clustered

Database server Este nodo representa el sistema de almacenamiento que se

maneja en la aplicacin de intermediacin comercial, el cual

esta implementado como un Storage Area Network (SAN).


2003 R2 SP2

Memory: 16 GB

CPU: Quad Core 3 GHz

Manufacter: Intel

SAN

Customer

application server

En este nodo se contempla el funcionamiento del componente

de pedidos y este tiene como funcin ofrecer un servidor de

aplicaciones independiente para los clientes de ArqSw que

interactan con la aplicacin intermediaria.

De igual manera, este nodo es implementado a travs de un

sistema de clster, con el fin de ofrecer balanceo de cargas y un

mecanismo de respaldo.


2003 R2 SP2

Memory: 64 GB



Manufacter: Intel

Clustered




Supplier

application server

Este nodo representa un servidor de aplicaciones independiente

que centraliza las interacciones de los proveedores con el

sistema de intermediacin comercial y al igual que el customer

application server, esta implementado en clster con el

propsito de proporcionar balanceo de cargas y un mecanismo

de respaldo.


2003 R2 SP2

Memory: 64 GB



Manufacter: Intel

Clustered

Firewall 2 Este dispositivo representa un cortafuegos, que regula y brinda

seguridad a las conexiones de las mquinas de los empleados

de ArqSw al corporate application server.

Model: ZyXEL ZyWALL 70

Manufacter: ZyWALL

ArqSw machine Este nodo representa a todas las mquinas que son manejadas

por los empleados de la compaa, para acceder al sistema de

intermediacin comercial por medio de sus web browser.


SP2

Memory: 1 GB

CPU: 1.8 GHz

Manufacter: Intel

4.1.3 Modelo de Red Con respecto a este modelo y teniendo en cuenta la figura 2, es posible visualizar que el server core de ArqSw maneja un ancho de banda en sus conexiones de 1 Gbps, con el fin de proporcionar transferencias de informacin de alta velocidad y soportar mltiples conexiones, con la ayuda de un protocolo de transporte como el TCP. Por otro lado, las conexiones que se establecen de manera remota con la aplicacin intermediaria, por parte de clientes y proveedores, se contemplan con velocidades aproximadas de 300 Kbps como mnimo, con el fin de contribuir al requerimiento de tiempos de respuesta rpidos. Sin embargo, dentro de la red de rea local de la compaa se ofrecen velocidades de mnimo 100 Mbps para las conexiones que se establecen desde las mquinas de los empleados de ArqSw, manejando protocolo HTTP; teniendo en cuenta que las interacciones que estos ltimos establecen con la aplicacin intermediaria se dan a travs de un ambiente Web. Es as que a continuacin, se describe de manera detallada las interfaces de interconexin de red que se proponen, para el correcto funcionamiento de la aplicacin intermediaria para ArqSw.



Tabla 7: Caractersticas de red en el Networking Model de la Aplicacin Intermediaria ArqSw

Conexin Caractersticas

Customer machine y Supplier machine Firewall 1 Protocol: HTTP

Port: 80

WAN

Bandwidth: 300 Kbps

Firewall 1 WEB server Protocol: TCP

Port: 4589

LAN

Bandwidth: 1 Gbps Ethernet

WEB server Corporate application server Protocol: TCP

Port: 5000

LAN


Corporate application server Customer application server Protocol: TCP

Port: 5001

LAN


Corporate application Server Customer application server Protocol: TCP

Port: 5002

LAN


Corporate application Server Database server Protocol: TCP

Port: 5003

LAN


Customer application server Supplier application server Protocol: TCP

Port: 5004

LAN


Customer application server Database server Protocol: TCP

Port: 5005



Conexin Caractersticas

LAN


Supplier application server Database server Protocol: TCP

Port: 5006

LAN


Corporate application server Firewall 2 Protocol: HTTP

Port: 5007

LAN


Firewall 2 ArqSw machine Protocol: HTTP

Port: 5007

LAN

Bandwidth: 100 Mbps Ethernet

4.1.4 Modelo de Dependencia Tecnolgica Tabla 8: Modelo de Dependencia Tecnolgica Aplicacin Intermediaria ArqSw

Componente Requiere

Customer, Supplier and ArqSw

machine


Memory: 256 MB or greater

CPU: 1.2 GHz

Manufacter: Intel or AMD

Web Browser

Database server OS: Microsoft Windows Server 2003 R2 SP2

Model Machine: Dell PowerEdge 1900

Memory: 16 GB

CPU: Quad Core 3 GHz

Manufacter: Intel

Oracle 10g

Storage System: EMC CX300 SAN Array, 421 GB

Clustered



Corporate application server

Model Machine: Blade Dell PowerEdge R900

OS: Microsoft Windows Server 2003 R2 SP2

Memory: 64 GB

CPU: 4 CPU Quad Core Xeon 7300 Series, 1066 MHz

Manufacter: Intel

JBoss 4.05 GA

Clustered

Customer application server Model Machine: Blade Dell PowerEdge R900


Memory: 64 GB


Manufacter: Intel

JBoss 4.05 GA

Clustered

WEB server OS: Microsoft Windows Server 2003 R2 SP2


Memory: 128 GB


Manufacter: Intel

Apache Tomcat 5.5

Clustered

Supplier application server



Memory: 64 GB


Manufacter: Intel

JBoss 4.05 GA

Clustered

Firewall

ZyWALL 70

WAN conection

VPN conection



4.2 Punto de Vista Funcional Para este viewpoint se realiz primero que todo un proceso de identificacin de los principales elementos arquitecturales por medio de los requerimientos funcionales y no funcionales reconocidos. De esta manera, se construy un modelo conceptual del sistema de intermediacin en el que se expresaron los elementos arquitecturales identificados al igual que las asociaciones existentes entre los mismos.

Posteriormente, se definieron un conjunto de responsabilidades especficas para cada uno de estos elementos identificados y de esta manera, se segment este diagrama conceptual de forma tal, que se pudieran definir unos subconjuntos de elementos arquitecturales con asociaciones e interacciones comunes.

Finalmente, se obtuvieron unos componentes funcionales con unas interfaces a travs de las cuales se ofrece un conjunto de servicios especficos, que complementan el funcionamiento a su vez de otros componentes.

4.2.1 Descripcin Por medio de los siguientes modelos de estructura funcional, es posible identificar que para esta arquitectura se conformaron 3 componentes referentes a procesos especficos de negocio para el sistema de intermediacin. Es as que se obtuvieron los componentes de Usuarios, Pedidos y Productos. Por otro lado es de gran importancia explicar que a cada uno de los componentes les fueron asignadas unas responsabilidades especficas y por ende, se les definieron unas interfaces con una serie de servicios discriminados, teniendo en cuenta que estas servirn como puentes de comunicaciones con otros componentes. Adems es necesario aclarar que no todos los servicios deban encapsularse a travs de una misma interfaz, dado que desde una perspectiva de seguridad y desempeo es aconsejable que los componentes receptores solo obtengan la informacin mnima necesaria para el desarrollo y ejecucin de sus propios procesos de negocio.

4.2.2 Procesos de Negocio Principales en ArqSw

Con el fin de desarrollar un conjunto de componentes funcionales con unos servicios adecuados para el sistema de intermediacin comercial, es indispensable identificar los principales procesos de negocio de ArqSw con el fin de utilizar esta caracterizacin, para evaluar el cumplimiento de las funciones desempeadas por las estructuras funcionales diseadas en busca de la realizacin de los casos de uso identificados. En ese orden de ideas, se describen a continuacin los procesos de negocio principales identificados.



4.2.2.1 Proceso de Realizacin de Pedidos

Figura 4: Aplicacin Intermediaria ArqSw: Proceso de Realizacin de Pedidos Como se puede apreciar en el presente diagrama de actividades, el proceso de realizacin de pedidos por parte de un cliente, inicia con el ingreso del mismo al sistema y su respectiva validacin. Luego, para este son activados una serie de servicios inherentes a su tipo de usuario. Posteriormente, el sistema solicita al cliente que elija el servicio a utilizar dentro de los cuales puede elegir la consulta de productos o el de listar los pedidos que ha ido acumulando en su respectivo carrito de compras. En ese orden de ideas, si se elige el servicio de consulta de productos, el sistema le solicita al cliente seleccionar el criterio de consulta, para luego ejecutar la bsqueda de



productos con la configuracin realizada. Posteriormente, el cliente puede decidir realizar el pedido sobre el producto seleccionado, estableciendo el nmero de unidades a solicitar teniendo en cuenta, que el sistema verificar que la cantidad configurada sea menor o igual a las existencias en el inventario. De esta manera, al final de este procedimiento el pedido del producto es registrado y actualizado como una nueva entrada en el carrito de compras del cliente, de forma tal que el sistema repite esta secuencia de pasos en un ciclo mientras se quiera seguir realizando la solicitud de productos. Por otro lado, el cliente podra optar por el servicio de listar pedidos, que bsicamente recupera el contenido del carrito de compras del cliente, con el fin de consultarlo y decidir si se desean realizar modificaciones o eliminaciones especficas de pedidos sobre el mismo. Finalmente, despus de utilizar cualquiera de los 2 servicios que ofrece el sistema para los clientes, es posible optar por no hacer nada ms y el sistema implementa el cierre de la sesin del cliente en cuestin.

4.2.3 Modelos de Estructura Funcional Como se mencion inicialmente, para la construccin de este functional viewpoint se comenz por identificar los principales elementos arquitecturales al igual que las asociaciones existentes entre los mismos, lo cual permiti construir el siguiente diagrama conceptual del sistema de intermediacin ArqSw.

Figura 5: Aplicacin Intermediaria ArqSw: Modelo Conceptual Teniendo en cuenta el anterior diagrama se defini una funcin especfica para cada uno de estos elementos arquitecturales identificados, y la descripcin de cada uno de los mismos se expresa a continuacin.



Tabla 9: Elementos Arquitecturales Identificados para la Aplicacin Intermediaria ArqSw

Elemento Arquitectural Funciones

Producto Entidad arquitectural que representa a todos los posibles

productos, que pueden administrarse por medio de la aplicacin

intermediaria, que son suministrados por los proveedores y

requeridos en ciertas cantidades por los clientes a travs de

pedidos especficos.

Proveedor Esta entidad arquitectural representa, a aquellas entidades o

personas que ofrecen sus productos, de acuerdo a unas

categoras de los mismos, especificadas y administradas bajo el

control del sistema de intermediacin comercial ArqSw.

Pedido Entidad que representa la solicitud de un cliente con respecto a

un producto determinado en una cantidad especfica, que se

establece de acuerdo a las existencias del producto en el

inventario.

Categora Entidad que representa una generalizacin para un cierto tipo de

productos, que son administrados bajo el sistema de

intermediacin comercial ArqSw.

Carrito de Compras Esta entidad representa el espacio donde el cliente, va

acumulando sus pedidos con respecto a una serie de productos y

unas cantidades determinadas, el cual permite la adicin,

modificacin y eliminacin de pedidos, con respecto al mismo

cliente.

Cliente Esta entidad representa a todas las personas que utilizan el

sistema de intermediacin, para realizar la solicitud de

productos de diferentes categoras y en variadas cantidades.

Ahora despus de esta identificacin de los elementos arquitecturales del sistema, tambin es necesario definir el significado de las asociaciones existentes entre los mismos y estas son descritas a continuacin. Tabla 10: Asociaciones entre Elementos Identificados para la Aplicacin Intermediaria

ArqSw

Asociacin Significado



ProductoProveedor Relacin que expresa que un proveedor puede ofrecer uno o

varios productos, bajo la administracin del sistema.

ProductoCategora Relacin que expresa que uno o varios productos pueden

pertenecer a una misma categora de productos.

ProductoPedido Relacin que expresa que un pedido solo puede estar compuesto

por un producto en una cantidad determinada del mismo.

PedidoCarrito de Compras Relacin expresa que el carrito de compras de un cliente, puede

estar compuesto por ningn o varios pedidos de productos.

Carrito de ComprasCliente Relacin que expresa que un cliente solo puede tener un carrito

de compras.

4.2.3.1 Algunas Justificaciones del Agrupamiento de Elementos Arquitecturales Ahora es necesario tener en cuenta, que la asignacin de colores realizada para cada uno de los elementos, no fue hecha de manera arbitraria, sino que a travs de esta convencin se expresa que cada uno de estos subconjuntos de elementos, evidencian una cohesin mucho mayor que la que existe entre los elementos de color diferente. Es as, que se decide que el elemento Producto guarda una mayor cohesin con el elemento de Categora, teniendo en cuenta que estos se realiza la caracterizacin de los productos ofrecidos para su consulta y venta en el sistema de intermediacin comercial. Por otra parte, se establece una asociacin entre el elemento de Pedido y el de Carrito de Compras, dado que por medio de estos se compone la descripcin completa de la solicitud tanto de los productos como de sus cantidades, por parte de un cliente especfico. Finalmente, los elementos de Proveedor y Cliente, fueron agrupados teniendo en cuenta que comparten el manejo del sistema, a pesar de utilizar diferentes servicios de acuerdo a sus roles de usuario. En ese orden de ideas, a continuacin se expondrn las responsabilidades que le fueron conferidas a cada uno de los elementos arquitecturales identificados y los servicios prestados por las interfaces de comunicacin construidas para los componentes conformados.



4.2.3.2 Diagramas de Composicin y Agregacin Teniendo en cuenta el anterior desarrollo conceptual, ahora es necesario definir una serie de interfaces de servicios, a travs de las cuales se ofrecer la posibilidad de implementar los procesos de negocio requeridos y especificados para el sistema de intermediacin comercial ArqSw. En ese orden de ideas, el diseo de interfaces propuesto comprende unas que permiten la realizacin de consultas y otras que permiten la administracin de las entidades funcionales anteriormente descritas y es as que se proponen los siguientes diagramas de composicin y agregacin.

4.2.3.3 Componente de Productos Como se puede apreciar en este diagrama de composicin y agregacin, para el componente de productos, se disean dos interfaces de servicios de consulta, a travs de las cuales es posible recuperar informacin por diferentes criterios, en relacin con las categoras y los productos ofrecidos por ArqSw. Por otro lado, las otras dos interfaces de servicios diseadas permiten la administracin tanto de las categoras como de los productos, en el sentido que ofrecen la posibilidad de controlar el ciclo de vida de estas entidades funcionales, a travs de procedimientos de registro, modificacin y cambio de estado, dando la oportunidad este ltimo de habilitar e inhabilitar categoras y productos en la aplicacin intermediaria ArqSw.

Figura 6: Aplicacin Intermediaria ArqSw: Diagrama de Composicin y Agregacin para el componente de Productos



4.2.3.4 Componente de Usuarios Para este caso, es necesario aclarar que aunque las entidades funcionales de proveedor y producto, no guardan relaciones de dependencia alguna; son agrupadas teniendo en cuenta que el componente del cual hacen parte, permite realizar un mejor control de roles de usuario de forma centralizada, para este sistema de intermediacin comercial. Es as, que por medio de este componentes se exponen cuatro interfaces de servicios, de las cuales dos son de consultas y las otras dos son de administracin, tanto de proveedores como de clientes; de forma tal que se puede recuperar informacin de estas dos entidades funcionales al igual que se posibilita, el registro, la modificacin y el cambio de estado para clientes y proveedores, que deseen controlarse desde esta aplicacin.

Figura 7: Aplicacin Intermediaria ArqSw: Diagrama de Composicin y Agregacin para el

componente de Usuarios

4.2.3.5 Componente de Pedidos Para la conformacin del componente de pedidos se decidi agrupar las entidades funcionales de pedido y carrito de compras, dada la relacin que existe entre las mismas. Es as, que el carrito de compras implementa la entidad funcional de pedido, dado que el carrito de un cliente puede estar compuesto por varios pedidos de productos en cantidades especficas. De esta manera, para este componente se exponen dos interfaces de servicios, a travs de las cuales es posible recuperar la informacin con respecto a todos los carritos de compras de los clientes, por diferentes criterios al igual que puede recuperarse el contenido de un carrito de compras especfico; y por otro lado, se construy una interfaz de administracin de pedidos, por medio de la cual se realiza el registro, modificacin y eliminacin de los mismos.



Figura 8: Aplicacin Intermediaria ArqSw: Diagrama de Composicin y Agregacin para el

componente de Pedidos

4.2.3.6 Diagrama de Componentes e Interfaces En este paso final y despus del anterior diseo de las interfaces de servicios para los componentes construidos, solo queda presentar cuales de estos requieren consumir servicios de otros, para la implementacin de sus procesos de negocio en el sistema de intermediacin comercial. En ese orden de ideas, el modelo funcional para la aplicacin intermediaria ArqSw es la siguiente.



Figura 9: Aplicacin Intermediaria ArqSw: Modelo de Componentes e Interfaces

Como se puede apreciar en el anterior diagrama, el componente de pedidos consume el servicio de consulta de productos, con el propsito de recuperar la informacin con respecto a los productos que son solicitados en determinadas cantidades y actualizados como registros en el carrito de compras del cliente. Por otro lado, es posible observar como tambin el servicio de administracin de productos es utilizado, dado que cada vez que se realiza un pedido, debe modificarse la entidad de producto para disminuir el nmero de existencias del mismo, en el inventario del sistema de intermediacin comercial.



4.3 Punto de Vista de Informacin Para el desarrollo de este punto de vista de informacin, se inici determinando las entidades informacionales con la ayuda del modelo de estructuras estticas de datos, el cual permiti adicionalmente identificar las asociaciones entre estas mismas unidades, expresando su cardinalidad.

Posteriormente, con la ayuda de este modelo y las entidades de informacin identificadas se detallaron los estados de estas, conformando finalmente los modelos de ciclo de vida de informacin para cada una de las mismas.

Luego, con la ayuda del punto de vista funcional se describi cual era el flujo de informacin a travs de los componentes desarrollados, construyendo de esta manera, el modelo de flujo de informacin para el sistema de intermediacin comercial ArqSw.

Finalmente, integrando los componentes desarrollados en el functional viewpoint y las entidades informacionales identificadas, se desarroll el modelo de propiedad de datos para cada una de las mismas.

4.3.1 Descripcin Para un entendimiento adecuado de este punto de vista de informacin y sin violar la independencia que existe entre los diferentes viewpoint del diseo arquitectural propuesto, es de gran utilidad observar la convencin de colores que se manej, con el fin de confirmar que para cada uno de los componentes diseados desde el functional viewpoint se estableci una correspondencia con las unidades de informacin que deberan manejar, dada su naturaleza especializada en el funcionamiento de la empresa ArqSw.

4.3.2 Modelo de Estructuras Estticas de Datos Por medio del siguiente modelo, se muestran las entidades de informacin ms importantes de en la arquitectura planteada, para el sistema de intermediacin comercial. Sin embargo, para entender de una mejor manera este modelo es necesario primero exponer las asociaciones existentes entre las unidades de informacin encontradas y luego, profundizar en los atributos y operaciones inherentes a estas mismas, como se presenta a continuacin.



4.3.2.1 Modelo General de Estructuras Estticas de Datos

Figura 10: Aplicacin Intermediaria ArqSw: Modelo General de Estructuras Estticas de Datos

De esta manera, puede observarse en este modelo general que la convencin de colores es equivalente a la usada en el functional viewpoint de manera intencional, para expresar el hecho de que unidades informacionales son usadas, manipuladas y administradas a travs de cada uno de los componentes planteados. En ese orden de ideas, las asociaciones anteriormente presentadas tienen los siguientes significados. Tabla 11: Asociaciones entre Entidades de Informacin para la Aplicacin Intermediaria

ArqSw

Asociacin Significado

ProductoCategora Expresa que la informacin de diferentes productos, puede estar

relacionada con una categora de productos particular.

PedidoProducto Expresa que la informacin de un pedido, solo puede estar

relacionada con la informacin referente a un solo producto.

Carrito de ComprasPedido Expresa que en un mismo carrito de compras, es posible

acumular la informacin de varios pedidos.

ClienteCarrito de Compras Expresa que para cada cliente solo hay un carrito de compras.



4.3.2.2 Modelo Detallado de Estructuras Estticas de Datos Teniendo en cuenta, la definicin de las anteriores asociaciones es conveniente, mostrar a continuacin los atributos y operaciones caractersticas de cada una de las entidades informacionales identificadas, as.

Figura 11: Aplicacin Intermediaria ArqSw: Modelo Detallado de Estructuras Estticas de Datos

Como se puede apreciar en la anterior figura y aumentando el nivel de detalle, es importante observar que los atributos de las entidades, son de cierta manera equivalentes a los atributos identificados para los componentes diseados en el punto de vista funcional, dado que estos ltimos tienden a manejar solo un subconjunto especfico de la unidades informacionales identificadas desde un punto de vista de sistemas de informacin en la aplicacin intermediaria.



4.3.3 Modelos de Ciclo de Vida de Informacin Aprovechando que el modelo de estructuras estticas de datos identifica las unidades informacionales del sistema, se definieron unos ciclos de vida con unos estados determinados para cada una de estas, como se muestra a continuacin.

4.3.3.1 Modelo de Ciclo de Vida de Informacin de Producto

Figura 12: Aplicacin Intermediaria ArqSw: Modelo de Ciclo de Vida de Informacin de Producto

Como se puede visualizar en la ilustracin anterior, los estados por los que pasa un producto, inician con la clasificacin del mismo dentro de una categora, de forma tal que si no existe categora alguna, el producto no puede ser registrado. Sin embargo, si se encuentra alguna categora para el producto en cuestin, este es registrado y habilitado en el sistema para ser ofertado. Sin embargo, los productos pueden ser modificados por los proveedores, en relacin a sus atributos y es por eso que, esta entidad puede pasar a un estado de modificacin, volviendo al estado de habilitado, tan pronto los cambios en sus caractersticas se hayan realizado.



Por ltimo, si se quiere dejar de oferta un producto en el sistema, es necesario cambiar su estado a deshabilitado y por ende, establecer a esta unidad informacional en dicho estado.

4.3.3.2 Modelo de Ciclo de Vida de Informacin de una Categora

Figura 13: Aplicacin Intermediaria ArqSw: Modelo de Ciclo de Vida de Informacin de una Categora

Como se puede observar en la anterior figura, el esquema de este ciclo de vida no es muy diferente del de producto, pero es necesario tener en cuenta que la importancia de este ciclo radica en el simple hecho, de que si esta entidad informacional no est disponible, ningn producto podra ser registrado a menos que su correspondiente categora haya sido registrada y habilitada por alguno de los administradores del sistema de intermediacin.



4.3.3.3 Modelo de Ciclo de Vida de Informacin de un Pedido

Figura 14: Aplicacin Intermediaria ArqSw: Modelo de Ciclo de Vida de Informacin de un Pedido

Para este ciclo, debe tenerse en cuenta, que la entidad informacional referente a un pedido determinado no podr registrarse, en el caso que durante el inicio o una fase de modificacin, el nmero de unidades del producto especificadas exceda, las disponibles dentro de las existencias del inventario.



4.3.3.4 Modelo de Ciclo de Vida de Informacin del Carrito de Compras

Figura 15: Aplicacin Intermediaria ArqSw: Modelo de Ciclo de Vida de Informacin del Carrito de Compras

Para el presente modelo no hay mayor complicacin, dado que simplemente expresa que el carrito de compras de un cliente y su informacin en el sistema, solo se puede encontrar en tres estados, los cuales comprenden la adicin, la modificacin y la eliminacin de los pedidos que se hayan realizado a travs del sistema.

4.3.3.5 Modelo de Ciclo de Vida de Informacin de Proveedor y Cliente

Figura 16: Aplicacin Intermediaria ArqSw: Modelo de Ciclo de Vida de Informacin de un Proveedor



Figura 17: Aplicacin Intermediaria ArqSw: Modelo de Ciclo de Vida de Informacin de un

Cliente

Como se puede apreciar en los anteriores de ciclos de vida de informacin, ni los clientes ni los proveedores, son eliminados alguna vez del sistema de intermediacin comercial, sino que ms bien son deshabilitados del mismo, impidiendo que estos sean validados al ingresar con sus roles de usuario.

4.3.4 Modelo de Propiedad de Datos Teniendo en cuenta los componentes desarrollados en el functional viewpoint y las entidades de informacin identificadas en el modelo de estructuras estticas de datos, se conforma la siguiente especificacin de permisos de lectura (L), modificacin (M) y creacin (C) , en las unidades informacionales.



Tabla 12: Modelo de Propiedad de Datos para la Aplicacin Intermediaria ArqSw

Prod

ucto

Cat

egor

a

Pedi

do

Car

rito

de

Com

pras

Prov

eedo

r

Clie

nte

Usuarios

Proveedores

LMC L LMC

Usuarios

Clientes

L L LMC LMC LMC

Usuarios

Administradores

LMC LMC LMC LMC LMC LMC

Productos LMC L

Pedidos L L LMC

4.3.5 Modelos de Flujo de Informacin A continuacin se muestran los diferentes flujos de informacin entre componentes y procesos en el sistema de intermediacin comercial ArqSw.

Figura 17: Aplicacin Intermediaria ArqSw: Modelo de Flujo de Informacin



5 Evaluacin de la Arquitectura

Despus de la descripcin con respecto a la infraestructura tecnolgica que debera soportar el sistema de intermediacin, el diseo funcional propuesto teniendo en cuenta los procesos de negocio principales y la definicin de las entidades informacionales y flujos de datos, se presenta la siguiente evaluacin arquitectural, con el fin de priorizar el grado de atencin que se debe tener con respecto a los requerimientos no funcionales planteados, proyectando el grado de accin que se debe ofrecer para la satisfaccin de los mismos.

5.1 rbol de Atributos de Calidad En ese orden de ideas, por medio del presente rbol de atributos de calidad mostramos la priorizacin de los requerimientos no funcionales para la presente arquitectura.

Figura 18: Aplicacin Intermediaria ArqSw: rbol de Atributos de Calidad

Como se puede apreciar en este rbol de atributos de calidad, es posible afirmar que los escenarios planteados en su mayora, tienen una dificultad alta de implementacin y adems, son crticos para la consecucin de los objetivos de la empresa. Sin embargo, a travs de estos quiere mostrase que representan factores de riesgo que conviene tener en cuenta en la implementacin de la arquitectura de software propuesta, a pesar de que por medio de los puntos de vista desarrollados se exhiba el cumplimiento de los requerimientos no funcionales identificados.



6 Referencias

DocumentingSoftwareArchitectures:ViewsandBeyonds,Clements,Paul.AdissonWesley,2002.

Software Systems Architectures Working with Stakeholders Using Viewpoints andPerspectives.RozanskiNick,WoodsEoin.AdissonWesley.2005.

PresentacionesdisponiblesparaelcursodeArquitecturadeSoftware.

TutorialJavaServerFaces.

Philippe KRUTCHEN. Common Misconceptions about Software Architecture. RationalSoftware2001.



7 Directorio

7.1 ndice

7.2 Glosario de Trminos

Trmino Definicin

software architecture

view

viewpoint

7.3 Acrnimos

Trmino Definicin

SAN Storage Area Network

Este documento es una adaptacin de la plantilla de documentacin propuesta por el Software

Engineering Institute (http://www.sei.cmu.edu/architecture/arch_doc.html). El documento ha sido

modificadoconalgunasideastomadasde:

DocumentingSoftwareArchitectures:ViewsandBeyonds,Clements,Paul.AdissonWesley,2002.

Software Systems Architectures Working with Stakeholders Using Viewpoints andPerspectives.RozanskiNick,WoodsEoin.AdissonWesley.2005.

ejemplo arqsw

Documents