ejemplo arqsw
Post on 01-Mar-2016
213 Views
Preview:
DESCRIPTION
TRANSCRIPT
-
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
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
-
Universidad de Los Andes Arquitectura de Software 2008-2
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
-
Universidad de Los Andes Arquitectura de Software 2008-2
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
-
Universidad de Los Andes Arquitectura de Software 2008-2
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
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 3
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
-
Universidad de Los Andes Arquitectura de Software 2008-2
4 ltima fecha de actualizacin: viernes, agosto 22, 2008
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 5
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
6 ltima fecha de actualizacin: viernes, agosto 22, 2008
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 7
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
8 ltima fecha de actualizacin: viernes, agosto 22, 2008
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
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 9
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
-
Universidad de Los Andes Arquitectura de Software 2008-2
10 ltima fecha de actualizacin: viernes, agosto 22, 2008
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
sistema de intermediacin comercial.
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
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 11
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
12 ltima fecha de actualizacin: viernes, agosto 22, 2008
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 13
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
-
Universidad de Los Andes Arquitectura de Software 2008-2
14 ltima fecha de actualizacin: viernes, agosto 22, 2008
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 15
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
16 ltima fecha de actualizacin: viernes, agosto 22, 2008
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 17
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
18 ltima fecha de actualizacin: viernes, agosto 22, 2008
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 19
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
20 ltima fecha de actualizacin: viernes, agosto 22, 2008
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 21
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
22 ltima fecha de actualizacin: viernes, agosto 22, 2008
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
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 23
Nodo Descripcin Caractersticas
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
sistema de intermediacin comercial.
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.
OS: Microsoft Windows Server
2003 R2 SP2
Memory: 128 GB
CPU: 4 CPU Quad Core Xeon
7300 Series, 1066 MHz
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).
OS: Microsoft Windows Server
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.
OS: Microsoft Windows Server
2003 R2 SP2
Memory: 64 GB
CPU: 4 CPU Quad Core Xeon
7300 Series, 1066 MHz
Manufacter: Intel
Clustered
-
Universidad de Los Andes Arquitectura de Software 2008-2
24 ltima fecha de actualizacin: viernes, agosto 22, 2008
Nodo Descripcin Caractersticas
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.
OS: Microsoft Windows Server
2003 R2 SP2
Memory: 64 GB
CPU: 4 CPU Quad Core Xeon
7300 Series, 1066 MHz
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.
OS: Microsoft Windows XP
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 25
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
Bandwidth: 1 Gbps Ethernet
Corporate application server Customer application server Protocol: TCP
Port: 5001
LAN
Bandwidth: 1 Gbps Ethernet
Corporate application Server Customer application server Protocol: TCP
Port: 5002
LAN
Bandwidth: 1 Gbps Ethernet
Corporate application Server Database server Protocol: TCP
Port: 5003
LAN
Bandwidth: 1 Gbps Ethernet
Customer application server Supplier application server Protocol: TCP
Port: 5004
LAN
Bandwidth: 1 Gbps Ethernet
Customer application server Database server Protocol: TCP
Port: 5005
-
Universidad de Los Andes Arquitectura de Software 2008-2
26 ltima fecha de actualizacin: viernes, agosto 22, 2008
Conexin Caractersticas
LAN
Bandwidth: 1 Gbps Ethernet
Supplier application server Database server Protocol: TCP
Port: 5006
LAN
Bandwidth: 1 Gbps Ethernet
Corporate application server Firewall 2 Protocol: HTTP
Port: 5007
LAN
Bandwidth: 1 Gbps Ethernet
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
OS: Microsoft Windows XP
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
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 27
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
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
WEB server OS: Microsoft Windows Server 2003 R2 SP2
Model Machine: Blade Dell PowerEdge R900
Memory: 128 GB
CPU: 4 CPU Quad Core Xeon 7300 Series, 1066 MHz
Manufacter: Intel
Apache Tomcat 5.5
Clustered
Supplier 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
Firewall
ZyWALL 70
WAN conection
VPN conection
-
Universidad de Los Andes Arquitectura de Software 2008-2
28 ltima fecha de actualizacin: viernes, agosto 22, 2008
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 29
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
-
Universidad de Los Andes Arquitectura de Software 2008-2
30 ltima fecha de actualizacin: viernes, agosto 22, 2008
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 31
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
-
Universidad de Los Andes Arquitectura de Software 2008-2
32 ltima fecha de actualizacin: viernes, agosto 22, 2008
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 33
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
-
Universidad de Los Andes Arquitectura de Software 2008-2
34 ltima fecha de actualizacin: viernes, agosto 22, 2008
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 35
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
36 ltima fecha de actualizacin: viernes, agosto 22, 2008
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 37
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
38 ltima fecha de actualizacin: viernes, agosto 22, 2008
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 39
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
40 ltima fecha de actualizacin: viernes, agosto 22, 2008
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 41
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
42 ltima fecha de actualizacin: viernes, agosto 22, 2008
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 43
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
-
Universidad de Los Andes Arquitectura de Software 2008-2
44 ltima fecha de actualizacin: viernes, agosto 22, 2008
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 45
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
-
Universidad de Los Andes Arquitectura de Software 2008-2
46 ltima fecha de actualizacin: viernes, agosto 22, 2008
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
ltima Fecha de Actualizacin: viernes, agosto 22, 2008 47
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.
-
Universidad de Los Andes Arquitectura de Software 2008-2
48 ltima fecha de actualizacin: viernes, agosto 22, 2008
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.
top related