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: af.ovalle316@uniandes.edu.co
Bogot D.C. 2008
Universidad de Los Andes - Arquitectura de Software 2008-1
Versin
5.0
Modificado Por
Fecha
Comentarios
Andrs Felipe
29 de
Entrega final del proyecto de la Aplicacin
Ovalle Crdenas
Julio de
Intermediaria ArqSw
2008
Universidad de Los Andes Arquitectura de Software 2008-2
Tabla de Contenido
1
1.1
Contexto ............................................................................................................ 5
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
Stakeholders ................................................................................................... 12
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
4.1
Puntos de Vista ............................................................................................... 21

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
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
5.1
Evaluacin de la Arquitectura ........................................................................46

rbol de Atributos de Calidad.........................................................46
Referencias ......................................................................................................47
Directorio..........................................................................................................48
7.1
ndice .................................................................................................48
7.2
Glosario de Trminos ......................................................................48
7.3
Acrnimos.........................................................................................48
ii
last saved: viernes, agosto 22, 2008
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:
Agregacin para el componente de Usuarios.............................................. 34

Figura 8:
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:
Informacin de una Categora ....................................................................... 41

Figura 14:
Informacin de un Pedido.............................................................................. 42
ltima Fecha de Actualizacin: viernes, agosto 22, 2008
Figura 15:
Informacin del Carrito de Compras .............................................................43

Figura 16:
Informacin de un Proveedor.........................................................................43
Figura 17:
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
ltima fecha de actualizacin: viernes, agosto 22, 2008
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

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

26
Elementos Arquitecturales Identificados para la Aplicacin

Tabla 10:
Asociaciones entre Elementos Identificados para la Aplicacin

Tabla 11:
Asociaciones entre Entidades de Informacin para la Aplicacin

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

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
Gerente Comercial
Descripcin
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.
Representa a la persona que solicita una serie de productos en
Cliente
determinadas cantidades de acuerdo a la oferta disponible, por

medio del sistema de intermediacin comercial.
Representa a las entidades encargadas de ofrecer el suministro
Proveedor
de productos, de acuerdo a las categoras comerciales

disponibles en el sistema de intermediacin comercial.
Simboliza una generalizacin de los proveedores, clientes y
Usuario
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
Ingresar al sistema
Descripcin
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
Caso de Uso
Descripcin
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
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
10
Caso de Uso
Descripcin
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.
11
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
Project manager
External organizations
Application software developers
Communications engineers
Operational system managers
Infrastructure software
developers
Chief Engineer/Chief Scientist
Trainers
Program management
Maintainers
End users
Auditors
Application system engineers
System and software integration

and test engineers
Security engineers and certifiers
Application hardware engineers
Tabla 3:
Safety engineers and certifiers
Listado de los Stakeholders para la Aplicacin Intermediaria ArqSw

Stakeholder
Gerente Comercial
Descripcin
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.
12
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.
Representa al grupo de personas encargadas del desarrollo,
Application Software Developers
mantenimiento y actualizacin de la aplicacin intermediaria

que se propone por medio de la arquitectura presentada.
Se refiere al personal especialista en la puesta en marcha,
Application Hardware Engineers
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.
Es el grupo de personas encargado de la configuracin,
Communications Engineers
supervisin y mantenimiento de las redes de comunicaciones

que maneja ArqSw para la transmisin de informacin.
Es el personal encargado, de brindar la orientacin y formacin
Trainers
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
13
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.
3.
Realizar consultas de productos a travs de diferentes criterios.

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.
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.
1.
Conocer la arquitectura de software, tecnologas, componentes y tiempo

requeridos para el desarrollo del software de intermediacin comercial para
ArqSw.
1.
Conocer los requerimientos tcnicos del software que ser utilizado y

caractersticas del hardware presente en ArqSw.
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.
14
Tabla 5:
Stakeholders y Viewpoints para la Aplicacin Intermediaria ArqSw
Stakeholder
Viewpoints
Gerente Comercial
Operational viewpoint, Deployment viewpoint.
Cliente
Operational viewpoint.
Proveedor
Operational viewpoint.
Concurrency viewpoint, Deployment viewpoint, Functional viewpoint e

Information viewpoint.
Functional viewpoint, Information viewpoint, Concurrency viewpoint,

Development viewpoint y Deployment viewpoint.
Information viewpoint, Concurrency viewpoint y Deployment viewpoint.
Information viewpoint, Concurrency viewpoint y Deployment viewpoint.
Trainers
Functional viewpoint y Operational viewpoint.
15
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.
16
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.
17
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.
18
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.
19
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.
20
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.
21
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,
Este nodo representa una mquina externa a ArqSw con las
OS: Microsoft Windows XP
Supplier and
caractersticas mnimas, que permiten interactuar con la
Memory: 256 MB or greater
ArqSw machine.
aplicacin intermediaria, por medio de un WEB browser.
CPU: 1.2 GHz

Manufacter: Intel or AMD
22
Nodo
Descripcin
Caractersticas
Firewall 1
Este dispositivo representa a los cortafuegos que regulan y
Model: ZyXEL ZyWALL 70
vigilan las conexiones entrantes al WEB server de ArqSw.
Manufacter: ZyWALL
Este nodo representa la mquina en la que se tiene instalado el
OS: Microsoft Windows Server
WEB server, en una organizacin de clster con el fin de
2003 R2 SP2
realizar un balanceo de cargas de las conexiones entrantes y un
Memory: 128 GB
conformar un sistema de respaldo para el acceso externo al
CPU: 4 CPU Quad Core Xeon
7300 Series, 1066 MHz
WEB server
Manufacter: Intel
Clustered
Corporate
Este nodo representa al servidor de aplicaciones corporativo en
application server
donde est el core de la aplicacin y a travs del cual se
2003 R2 SP2
distribuyen los servicios prestados por el componente de
Memory: 128 GB
usuarios (clientes, proveedores, administradores, etc.) a los
dems servidores de aplicaciones de la compaa. De esta
manera, se puede proporcionar escalabilidad al sistema por
Manufacter: Intel
medio de este nodo.
Clustered
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.
Database server
Este nodo representa el sistema de almacenamiento que se
maneja en la aplicacin de intermediacin comercial, el cual
2003 R2 SP2
esta implementado como un Storage Area Network (SAN).
Memory: 16 GB
CPU: Quad Core 3 GHz
Manufacter: Intel
SAN
Customer
En este nodo se contempla el funcionamiento del componente
application server
de pedidos y este tiene como funcin ofrecer un servidor de
2003 R2 SP2
aplicaciones independiente para los clientes de ArqSw que
Memory: 64 GB
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.

Manufacter: Intel
Clustered
23
Nodo
Descripcin
Caractersticas
Supplier
Este nodo representa un servidor de aplicaciones independiente
application server
que centraliza las interacciones de los proveedores con el
2003 R2 SP2
sistema de intermediacin comercial y al igual que el customer
Memory: 64 GB
application server, esta implementado en clster con el
propsito de proporcionar balanceo de cargas y un mecanismo
de respaldo.
Manufacter: Intel
Clustered
Firewall 2
Este dispositivo representa un cortafuegos, que regula y brinda
Model: ZyXEL ZyWALL 70
seguridad a las conexiones de las mquinas de los empleados
Manufacter: ZyWALL
de ArqSw al corporate application server.

ArqSw machine
Este nodo representa a todas las mquinas que son manejadas
por los empleados de la compaa, para acceder al sistema de
SP2
intermediacin comercial por medio de sus web browser.
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.
24
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
25
Conexin
Caractersticas
LAN
Protocol: TCP
Supplier application server Database server
Port: 5006
LAN
Protocol: HTTP
Corporate application server Firewall 2
Port: 5007
LAN
Protocol: HTTP
Firewall 2 ArqSw machine
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
26
Corporate application server
Model Machine: Blade Dell PowerEdge R900

Memory: 64 GB
CPU: 4 CPU Quad Core Xeon 7300 Series, 1066 MHz
Manufacter: Intel
JBoss 4.05 GA
Clustered
Customer application server

Memory: 64 GB
Manufacter: Intel
JBoss 4.05 GA
Clustered
WEB server

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
27
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.
28
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
29
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.
30
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
31
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.
32
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
33
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.

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.
34

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.
35
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.
36
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.
37
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
38
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.
39
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.
40
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.
41
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.
42
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

Proveedor
43

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.
44
Usuarios
LMC
LMC
LMC
LMC
LMC
LMC
LMC
Productos
LMC
Pedidos
Cliente
Proveedor
Compras
Carrito de
Pedido
Producto
Categora
Tabla 12: Modelo de Propiedad de Datos para la Aplicacin Intermediaria ArqSw
LMC
Proveedores
Usuarios
LMC
Clientes
Usuarios
LMC
LMC
Administradores
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
45
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.
46
6 Referencias
DocumentingSoftwareArchitectures:ViewsandBeyonds,Clements,Paul.AdissonWesley,
2002.
Software Systems Architectures Working with Stakeholders Using Viewpoints and

Perspectives.RozanskiNick,WoodsEoin.AdissonWesley.2005.
PresentacionesdisponiblesparaelcursodeArquitecturadeSoftware.
TutorialJavaServerFaces.
Philippe KRUTCHEN. Common Misconceptions about Software Architecture. Rational

Software2001.
47
7 Directorio
7.1 ndice
7.2 Glosario de Trminos
Trmino
Definicin
software architecture
view
viewpoint
7.3 Acrnimos
Trmino
SAN
Definicin
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 and

Perspectives.RozanskiNick,WoodsEoin.AdissonWesley.2005.
48

Ejemplo ArqSW

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ejemplo ArqSW

Uploaded by

Copyright:

Available Formats

Universidad de Los Andes

Aplicacin Intermediaria ArqSw

Nombre de los Integrantes:

Andrs Felipe Ovalle Crdenas

Bogot D.C. 2008

Universidad de Los Andes - Arquitectura de Software 2008-1

Entrega final del proyecto de la Aplicacin

Universidad de Los Andes Arquitectura de Software 2008-2

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

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

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

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

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

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

last saved: viernes, agosto 22, 2008

Universidad de Los Andes Arquitectura de Software 2008-2

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

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

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

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

last saved: viernes, agosto 22, 2008

Universidad de Los Andes Arquitectura de Software 2008-2

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

Aplicacin Intermediaria ArqSw: Runtime and Networking Model22

Aplicacin Intermediaria ArqSw: Proceso de Realizacin de Pedidos

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

Aplicacin Intermediaria ArqSw: Diagrama de Composicin y

Agregacin para el componente de Productos ........................................... 33

Aplicacin Intermediaria ArqSw: Diagrama de Composicin y

Agregacin para el componente de Usuarios.............................................. 34

Aplicacin Intermediaria ArqSw: Diagrama de Composicin y

Agregacin para el componente de Pedidos ............................................... 35

Aplicacin Intermediaria ArqSw: Modelo de Componentes e

Aplicacin Intermediaria ArqSw: Modelo General de Estructuras

Estticas de Datos .......................................................................................... 38

Aplicacin Intermediaria ArqSw: Modelo Detallado de Estructuras

Estticas de Datos .......................................................................................... 39

Aplicacin Intermediaria ArqSw: Modelo de Ciclo de Vida de

Informacin de Producto ............................................................................... 40

Aplicacin Intermediaria ArqSw: Modelo de Ciclo de Vida de

Informacin de una Categora ....................................................................... 41

Aplicacin Intermediaria ArqSw: Modelo de Ciclo de Vida de

ltima Fecha de Actualizacin: viernes, agosto 22, 2008

Universidad de Los Andes Arquitectura de Software 2008-2

Aplicacin Intermediaria ArqSw: Modelo de Ciclo de Vida de

Informacin del Carrito de Compras .............................................................43

Aplicacin Intermediaria ArqSw: Modelo de Ciclo de Vida de

Aplicacin Intermediaria ArqSw: Modelo de Ciclo de Vida de

Aplicacin Intermediaria ArqSw: Modelo de Flujo de Informacin45

Aplicacin Intermediaria ArqSw: rbol de Atributos de Calidad 46

ltima fecha de actualizacin: viernes, agosto 22, 2008

Universidad de Los Andes Arquitectura de Software 2008-2

Actores contemplados para la Aplicacin Intermediaria ArqSw .. 8

Casos de Uso contemplados para la Aplicacin Intermediaria ArqSw

Listado de los Stakeholders para la Aplicacin Intermediaria ArqSw

Stakeholders y Concerns para la Aplicacin Intermediaria ArqSw13

Stakeholders y Viewpoints para la Aplicacin Intermediaria ArqSw

Nodos identificados para el Runtime Model de la Aplicacin

Intermediaria ArqSw ....................................................................................... 22

Caractersticas de red en el Networking Model de la Aplicacin

Intermediaria ArqSw ....................................................................................... 25

Modelo de Dependencia Tecnolgica Aplicacin Intermediaria

Intermediaria ArqSw ....................................................................................... 31

Asociaciones entre Elementos Identificados para la Aplicacin