TABLA DE CONTENIDO

1. INTRODUCCIÓN ........................................................................................................................... 3
1.1. Resumen .............................................................................................................................. 3
1.2. Alcance ................................................................................................................................ 3
1.3. Terminología ....................................................................................................................... 4
2. CONTEXTO ................................................................................................................................... 4
2.1. Caso de estudio: .................................................................................................................. 4
3. ANÁLISIS DE LA ARQUITECTURA ................................................................................................. 6
3.1. Lista de los stakeholders y sus preocupaciones. ................................................................. 6
3.2. Restricciones sobre la arquitectura (técnicas, costos y tiempo). ........................................ 8
3.3. Conductores de la arquitectura. ......................................................................................... 8
3.4. Conductores del negocio..................................................................................................... 8
3.5. Requerimientos funcionales ............................................................................................... 8
3.6. Requerimientos no funcionales .......................................................................................... 9
3.7. Riesgos del proyecto. .......................................................................................................... 9
3.8. Escenarios de calidad. ......................................................................................................... 9
4. REPRESENTACIÓN DE LA ARQUITECTURA ................................................................................. 12
4.1. Diagrama de contexto ....................................................................................................... 12
4.2. Vistas de la arquitectura Modelo 4+1. .............................................................................. 13
4.2.1. Vista de escenarios: ....................................................................................................... 14
4.2.2. Vista lógica: ................................................................................................................... 17
4.2.3. Vista de implementación: ............................................................................................. 18
4.2.4. Vista de procesos: ......................................................................................................... 20
4.2.5. Vista de despliegue: ...................................................................................................... 22
5. TÁCTICAS, ESTRATEGIAS Y PATRONES DE ARQUITECTURA ...................................................... 24
6. COMPONENTES COTS................................................................................................................ 24
7. SUPUESTOS................................................................................................................................ 25
 TABLA DE IMÁGENES

Figura 1. Definition Modelo 4+1 ......................................................................................................... 3

Figura 2. Diagrama de Contexto ........................................................................................................ 13
Figura 3. Vista de arquitectura 4+1 ................................................................................................... 13
Figura 4. Diagrama de Casos de uso, sistema general ...................................................................... 14
Figura 5. Diagrama de casos de uso integración sistemas ................................................................ 14
Figura 6. Vista lógica.......................................................................................................................... 17
Figura 7. Representación vista de implementación .......................................................................... 19
Figura 8. Elementos vista de proceso................................................................................................ 20
Figura 9. Vista de procesos................................................................................................................ 21
Figura 10. Vista de Despliegue .......................................................................................................... 23
1. INTRODUCCIÓN

1.1. Resumen
Este documento de arquitectura de software tiene como objetivo definir la estructura
que permitirán cumplir a nivel funcional los requerimientos especificados a partir del
caso de estudio planteado, buscando el mejoramiento del sistema de compra de partes
con los distribuidores por medio de un sistema de subasta para escoger la mejor oferta
propuesta por los proveedores, además busca tener acceso a proveedores nacionales
e internacionales.

La arquitectura que aquí se define permite presentar las bases técnicas y tecnológicas
sobre las que estará construido el sistema y buscará cubrir los requisitos funcionales y
de calidad críticos, así como direccionar a grandes rasgos el diseño y desarrollo.

1.2. Alcance
Los aspectos y elementos de arquitectura definidos en este documento se basan en las
necesidades y requisitos funcionales - no funcionales del caso de estudio presentado
de la empresa Car Advance. La arquitectura definida para el sistema de subastas
invertidas corresponde a una definición de alto nivel, desde la perspectiva estratégica
del negocio, pero no pretende llegar a un diseño detallado de la solución de
implementación; reflejando las diferentes decisiones sobre la plataforma tecnológica
seleccionada y estableciendo directrices básicas para el diseño y desarrollo,
asegurando que la solución arquitectónica sea viable para las necesidades propuestas.

La representación arquitectónica está basada en el Modelo de vista 4+1, el cual se

compone de:

Figura 1. Definition Modelo 4+1

 Este modelo permite que el personal involucrado en el proyecto entienda la
complejidad de un sistema y tenga una visión diferente de lo que se está
implementando sin necesidad de tener conocimientos sobre arquitectura de software.

1.3. Terminología

● Arquitectura de software: La Arquitectura del Software es el diseño de más alto nivel

de la estructura de un sistema, consiste en un conjunto de patrones y abstracciones
coherentes que proporcionan el marco de referencia necesario para guiar la
construcción del software para un sistema de información, y establece de manera
abstracta, los componentes que llevan a cabo alguna tarea de computación, sus
interfaces y la comunicación entre ellos.
● Stakeholder: Son todas aquellas personas u organizaciones que afectan o son
afectadas por el proyecto, ya sea de forma positiva o negativa.
● Vista: Una vista es una representación de uno o más aspectos estructurales de una
arquitectura que ilustra cómo la arquitectura se ocupa de uno o más concerns
estipulados por uno o más Stakeholders.
● Modelo vista 4+1: Vistas permite ofrecer una representación arquitectónica del
sistema desde diferentes perspectivas con el fin de ofrecer elementos de decisión a los
diferentes roles involucrados en el desarrollo de la solución informática y para
identificar los elementos más significativos del sistema.
● Atributo de calidad: Característica de un componente o sistema. Deben ser
diseñados y evaluados en la definición de una arquitectura.
● Escenario de calidad: Permiten detallar en qué condiciones y de qué manera debe
cumplirse un atributo de calidad. Son casos concretos en los que podremos evidenciar
si el sistema cumple o no con un atributo de calidad.
● Servicio: Conjunto de actividades que buscan responder a necesidades de un cliente
● GUI: Interfaz Gráfica de Usuario, son las pantallas que el usuario ve y con las que
interacciona.

2. CONTEXTO

2.1. Caso de estudio:

Car Advance es una manufacturera de vehículos que ensambla y distribuye vehículos

en Europa y Latinoamérica. Sin embargo, sus ventas en los últimos años han
disminuido en un 20% y se estima que los próximos años seguirán disminuyendo.
Después de hacer un estudio de mercado y de conocer la opinión de sus principales
clientes se encontró que Car Advance, frente a otras compañías manufactureras,
ofrece menos beneficios en términos de costos, tiempos de entrega y calidad de las
partes usadas.

La alta gerencia considera que la razón principal en que el mercado local de partes
(llantas, frenos, suspensión, sillas, etc.) es escaso y costoso afectando la calidad y
tiempos de entrega de sus productos. De este modo, se ha evaluado la posibilidad de
implementar una nueva aplicación de subastas en reversa que permita, tanto a
distribuidores locales como internacionales, realizar ofertas.

En una etapa inicial de definición del negocio, se recolecto las expectativas de los
principales stakeholders.

● Alta Gerencia: El nuevo sistema debe apoyar la reducción de costos operativos y

disminuir el tiempo de ensamblaje de los vehículos.
● Distribuidores: Sería deseable que podamos integrar nuestros sistemas con el
sistema de Car Advance con un mínimo de esfuerzo. No obstante, también
debemos poder utilizar el portal de la compañía para poder realizar ofertas en el
caso de no podernos comunicar directamente con el sistema.
● Área de tecnología: La implementación de un sistema como este agilizará el
proceso de ensamblaje de los vehículos considerablemente. Sin embargo, se debe
minimizar los costos de administración y mantenimiento por lo que su
implementación debe ser adecuadamente realizada y documentada.
Adicionalmente, se requiere que el sistema sea implementado en menos de 4
meses y esperamos que se construido con tecnología de punta.

En esta primera etapa de desarrollo se implementarán la siguiente funcionalidad:

● Solicitar partes. Permite a un usuario de autorizado de Car Advance solicitar una

cantidad requerida de partes. Una solicitud tiene una categoría (llantas, frenos,
amortiguadores, etc) y una cantidad. El sistema debe crear la subasta
correspondiente y dejar la solicitud en estado abierta para que pueda ser
consultada.
● Consultar ofertas. Permite a un usuario autorizado de Car Advance consultar las
solicitudes que se encuentran abiertas y ver las ofertas que tienen asociadas.
● Enviar oferta. Permite a un proveedor autorizado enviar una oferta por una solicitud
de adquisición de partes en estado abierta. El sistema debe registrar todas las
ofertas realizadas.
● Emitir orden de compra al proveedor ganador. Cuando se termina una subasta.
El sistema verifica la oferta con menor valor y envía al proveedor ganador una orden
de compra por la parte y cantidad de la solicitud
● Actualizar inventario de partes. Después de que se termina una subasta el
sistema actualiza el inventario interno de partes.

Como este nuevo mecanismo se convertirá en la estrategia escogida para soportar el

proceso de negocio de la compañía se espera que el sistema provea la siguiente
funcionalidad:
● El sistema debe estar disponible 24x7 ya que una su indisponibilidad puede afectar
la fecha de entrega de los vehículos y ocasionar problemas con los clientes.
● Se estima que al sistema accederán 50 usuarios de manera concurrente. Sin
embargo, se estima que este número de clientes puede aumentar en un 50%
después de dos meses de estar el sistema funcionando.
● Inicialmente, el sistema soportará el registro de frenos de disco y llantas. A medida,
que el sistema adquiera reconocimiento en el mercado, el sistema debe soportar el
ingreso de nuevos componentes sin mayor impacto.
 ● Recientemente, Car Advance ha invertido en un sistema de inventario que puede
predecir la demanda que tendrá una parte. Se requiere que el sistema de subastas
consulte esta predicción para poder crear subastas por las partes que mayor
demanda tienen. Adicionalmente, este sistema debe ser usado para actualizar el
inventario de las partes disponibles. Este sistema puede accederse vía web
services.
● El mecanismo de integración que los proveedores usarán para realizar las ofertas
deben responder en menos de 5 segundos.

3. ANÁLISIS DE LA ARQUITECTURA

3.1. Lista de los stakeholders y sus preocupaciones.

Stakeholder Ocupación Preocupaciones

Alta Gerencia Jefes inmediatos de los El posicionamiento de la empresa,

funcionarios de la además que el sistema permita la
empresa; son los reducción de costos operativos y la
responsables de disminución del tiempo de ensamblaje de
establecer los los vehículos.
requerimientos del
sistema.

Distribuidores Encargados de realizar Que se agilice y se facilite el proceso

las ofertas de los actual a partir de la integración de sus
repuestos ofrecidos por sistemas con el sistema de Car Advance
la compañía. con un mínimo de esfuerzo. Además que
cuando la conexión entre estos no esté
disponible se pueda utilizar el portal
actual de la empresa para realizar las
ofertas.

Área de Encargados de realizar Que el sistema de Car Advance se

tecnología el mantenimiento, pueda integrar con el sistema de
configuración y gestión inventario que se tiene actualmente y
del software. que el desarrollo del sistema no tarde
más de 4 meses.
 Jefe de Encargado de Tener una aplicación de fácil uso e
almacenamiento supervisar el inventario intuitiva que presente información
de la empresa Car correspondiente a las entregas que
Advance. llegan (coherencia) y que sea rápida a la
hora de asignar la mercancía recibida
(Desempeño). Además espera
centralizar por completo el inventario de
partes ya que esta a su cargo los
ingresos y egresos que se realicen.

Trabajador de Encargado del Espera que se agilice la obtención de

producción ensamblaje de los partes y la consulta del inventario para
automóviles con los que estos puedan ser información
suministros contratados fidedigna sobre la materia prima para
por medio del sistema. producir.

Analista de Encargado de abrir la Que con la implementación del sistema

Mercado convocatoria para el la empresa tenga un muy buen
suministro de partes posicionamiento, además, espera que
por medio de la contribuya al buen desarrollo de la
subasta invertida. contratación de los proveedores que
ganen las subastas invertidas.

Equipo de Encargado de la Que el desarrollo del proyecto se cumpla

desarrollo implementación y entre las reglas establecidas, teniendo en
desarrollo del sistema cuenta de que estas sean alcanzables,
Car Advance. además que no hayan cambios
sustanciales en los requerimientos para
que no se tengan retrasos en el proyecto.

También que el sistema de inventario y el

portal de la empresa puedan ser
fácilmente acoplados al proyecto

Gerente del Identifica riesgos y Que el proyecto sea viable entre los
proyecto (Project supervisa las diferentes acuerdos estipulados (tiempo - costo -
Manager) etapas del proyecto. recursos disponibles). Además que el
producto terminado sea entregado a
satisfacción a la empresa Car Advance.

Clientes de Car Compra el producto Que a partir de la implementación de la

Advance que ofrece la empresa solución se disminuyan costos, se agilice
Car Advance. el proceso de producción y que el
producto final sea de mayor calidad.
3.2. Restricciones sobre la arquitectura (técnicas, costos y tiempo).

● El sistema debe realizarse en 4 meses y con Tecnología de punta.

● El sistema debe diseñarse visualmente para ser compatible con diferentes
dispositivos como tablets y smartphones.
● El costo de desarrollo del sistema no puede ser mayor las ganancias generadas a
partir de la implementación del sistema.
● Se debe tener una arquitectura tal que permita a otros sistemas integrarse a la
subastas del sistema.
● La arquitectura debe permitir integrarse con el sistema actual de la compañía.
● Debe ser a través de navegación Web, personalizable a partir del dispositivo.

3.3. Conductores de la arquitectura.

“Dada la libertad total, el trabajo es propenso a expandirse”(codingthearchitecture,

2013)
T.S.Eliot

● La implementación debe ser justificada y documentada.

● Se debe facilitar la configuración de componentes a través de un sistema
administrable.
● Se debe soportar la escalabilidad en el sistema, de acuerdo a concurrencia y
funcionalidad.
● Agilizar y controlar los procesos de generación de una orden de compra.
● Se debe automatizar las subastas, conforme a un sistema de Business Intelligence.

3.4. Conductores del negocio

● Se debe apoyar la reducción de costos y optimización de tiempos.

● Se debe satisfacer la escasez de productos.
● Se deben reducir los tiempos de entrega de los productos.
● Debe mejorar la calidad de los productos entregados.
● Se debe aumentar la satisfacción de los clientes.
● Aumentar la cantidad de productos disponibles.

3.5. Requerimientos funcionales

● El sistema debe permitir realizar ofertas por parte de los proveedores

● De brindar la posibilidad de crear una subasta en reversa.
● Permitir la consulta y el estado de las subastas creadas, así como sus respectivas
ofertas asociadas.
● Debe generar órdenes de compra para informarle al proveedor que ha sido el
ganador.
● Cuando se tiene un ganador de la subasta y se llega a un acuerdo el sistema de
inventarios se debe actualizar
 ● Se debe generar subastas automáticamente a partir de la escasez de productos o el
comportamiento del stock del inventario.

3.6. Requerimientos no funcionales

● Debe estar disponible 24x7

● El tiempo de respuesta de un sistema integrado de un proveedor no debe ser mayor
a 5 segundos.
● La interfaz gráfica de usuario será fácil de usar, amigable al usuario e intuitiva.
● Los mensajes informativos, de advertencia o error deben ser manejados y
presentados por la aplicación; éstos deben ser claros y precisos, evitando involucrar
tecnicismos o presentando información que no es útil al usuario de la aplicación.
● Debe ser escalable, permitiendo un gran aumento en la carga de usuarios.
● Debe permitir una fácil integración con otros sistemas.
● El sistema debe ser fácilmente modificable.

3.7. Riesgos del proyecto.

Como todo proyecto de software, siempre se tendrán riesgos o amenazas en base a la

incertidumbre que se puede tener. Estos pueden ser:

● Técnicos: Estos riesgos son en base al desarrollo del software.

○ Mal diseño de la arquitectura a implementar
○ Cambio en los requerimientos del sistema
○ El sistema no esté disponible 24x7, debido a problemas con el prestador de
servicios de internet.
○ Problemas para acoplar el sistema con el sistema actual de inventario.
● Del negocio: Caracterizados por el núcleo del proyecto, o el cliente quien lo solicita.
○ No aceptación del sistema por parte de los usuarios:
○ Cambios de enfoque por parte de la alta gerencia
○ Cambio del personal de la alta gerencia
○ Cambio en el presupuesto o tiempo asignado para el desarrollo del proyecto.
○ Mala identificación del problema principal por parte de la gerencia.
○ El aumento de usuarios para el uso del sistema sea mucho mayor a lo esperado.

3.8. Escenarios de calidad.

A continuación se detallan los diferentes escenarios de calidad, teniendo en cuenta que

se han dispuesto de manera priorizada:

Disponibilidad

Interna (Módulo ofertas) Fuente

Timing Estímulo
Sistema Artefacto

Operación Normal Entorno

El sistema de monitoreo externo detecta la indisponibilidad del Respuesta

servicio, registra en el log las causas posibles, envía notificación al
administrador y a los proveedores para que usen el portal para
registrar sus ofertas

La indisponibilidad se detecta en menos de 1 minuto Medida de la

El sistema continúa funcionando a través del portal respuesta

Disponibilidad

Externa Fuente

Caída Estímulo

Sistema Artefacto

Sobrecargado Entorno

El sistema cuenta con una garantía de calidad de 24x7, entonces Respuesta

se tendrá una redirección a un sistema espejo. Además de enviar
notificación a los implicados para la solución de los inconvenientes

El sistema se encuentra en funcionamiento 99.6% del tiempo, por Medida de la

lo tanto, sigue funcionando respuesta

Rendimiento

Sistema de proveedores Fuente

Eventos periódicos Estímulo

Sistema de integración Artefacto

Sobrecargado Entorno

El sistema registra los eventos en el log, prioriza los procesos e Respuesta

indica al usuario que se está procesando la solicitud

Deadline inferior a 5 segundos Medida de la

respuesta
Rendimiento

Sistema de proveedores Fuente

Eventos periódicos Estímulo

Sistema de integración Artefacto

Operación normal Entorno

El sistema registra los eventos en el log, procesa la solicitud del Respuesta

usuario de forma inmediata después de su recepción

Latencia inferior a 5 segundos Medida de la

respuesta

Modificabilidad

Desarrollador del sistema Fuente

Agregar funcionalidad Estímulo

Módulo registro componentes Artefacto

Diseño / Desarrollo Entorno

Se incluyen las modificaciones de los componentes y se despliegan Respuesta

los cambios en runtime

El cambio es realizado en un tiempo no superior a 30 minutos, pero Medida de la

contará con un tiempo total de 3 horas para el testeo de esta nueva respuesta
funcionalidad. Habrá solo 1 elemento afectado (fichero de
configuración), involucrando máximo 1 desarrollador

Seguridad

Individuo identificado y autorizado, que no tiene permisos de acceso Fuente

Consultar datos Estímulo

Datos del sistema Artefacto

En línea Entorno

Se redirecciona a una página indicando que no tiene permisos para Respuesta

acceder al servicio seleccionado. Se ingresa el intento en la base
de datos de auditoría
El 100% de los intentos (fallidos/válidos) se registran en log de Medida de la
auditoría respuesta

Usabilidad

Usuario final Fuente

El usuario quiere aprender sobre el registro de solicitud de partes Estímulo

Sistema Artefacto

Runtime Entorno

El usuario encuentra que las interfaces manejan un estándar Respuesta

además contienen una opción para consultar ayudas de contexto

El nivel de satisfacción del usuario es mayor al 80% de acuerdo a Medida de la

encuesta realizada respuesta

Capacidad de prueba

Integrador Fuente

Sistema liberado Estímulo

Módulo de la aplicación integrado Artefacto

Deploy Entorno

Proporciona valores estadísticos a medida que se van ejecutando Respuesta

los Tests

Porcentaje de cobertura testeado mayor o igual a 85% Medida de la

respuesta

4. REPRESENTACIÓN DE LA ARQUITECTURA

4.1. Diagrama de contexto

El siguiente diagrama muestra de manera global cómo será la interacción entre los
diferentes sistemas y las personas interesadas en el proyecto. Se tiene el sistema de
Car Advance que será desarrollado junto al portal, los cuales podrán ser accedidos
para realizar las diferentes operaciones solicitadas en el proyecto. El sistema de Car
Advance se comunicara con el sistema de proveedores para que realicen sus ofertas
respectivas y con el sistema de inventario para actualizar los productos disponibles
luego de una subasta.
 Figura 2. Diagrama de Contexto

4.2. Vistas de la arquitectura Modelo 4+1.

Para cada vista se define un conjunto de elementos (componentes, contenedores y
conectores), se capta la forma y los patrones con que trabajan, la justificación y las
restricciones, relacionando la arquitectura con algunos de sus requisitos.
Cada vista se describe en lo que se conoce como “diagrama” (blueprint), que usan una
notación particular. Los arquitectos también pueden usar estilos de arquitectura para
cada vista, y por lo tanto hacer que coexistan distintos estilos en un mismo sistema.

El modelo de vistas 4+1 es bastante genérico, es decir, se puede usar otra notación y
herramientas de que las se describen comúnmente, también se pueden utilizar otros
métodos de diseño, especialmente para las descomposiciones lógica y de procesos.
(Kruchten, 2011)

Figura 3. Vista de arquitectura 4+1

4.2.1. Vista de escenarios:
A partir de los requerimientos funcionales del proyecto, se identificaron los
siguientes casos de uso:

● Gestión subastas (crear, eliminar, buscar)

● Gestión de inventario de partes (crear, actualizar, eliminar, buscar)
● Crear y buscar ofertas
● Búsqueda y notificación de resultado subastas.

Figura 4. Diagrama de Casos de uso, sistema general

Figura 5. Diagrama de casos de uso integración sistemas

 Crear subasta

Permite a un usuario de autorizado de la empresa crear una subasta para Descripción

que los proveedores puedan participar en ella. Entre las subastas se
pueden solicitar las siguientes partes: Llantas, frenos, amortiguadores, con
su respectiva cantidad; en una fase posterior el usuario puede crear una
parte nueva para poder solicitarla en la subasta. Esta subasta creada
queda para acceso público de los proveedores para que puedan participar
en esta, siempre y cuando la subasta esté en estado abierto.

Muy alto Impacto

Empleado de la empresa Actores

Eliminar subasta

Permite a un usuario de autorizado de la empresa eliminar una subasta Descripción

creada previamente.

Medio Impacto

Empleado de la empresa Actores

Consultar subasta

Permite a un usuario del sistema consultar las características y el Descripción

estado de una subasta creada previamente.

Media Impacto

Empleado de la empresa Actores

Buscar ofertas

Permite a un usuario del sistema consultar las diferentes ofertas Descripción

realizadas por los proveedores para una determinada subasta.

Baja Impacto

Empleado de la empresa Actores

Consultar resultado
subasta

Permite consultar los resultados de una determinada subasta, Descripción

mostrando quien fue el proveedor ganador.
Muy alto Impacto

Empleado de la empresa, proveedor Actores

Crear oferta

Permite a un proveedor enviar una oferta y relacionarla a una subasta Descripción

publicada.

Muy alto Impacto

Proveedor Actores

Cerrar subasta

El sistema cierra una subasta cuando llega su fecha límite, cambia Descripción
su estado y verifica quien es el proveedor ganador.

Muy alto Impacto

Sistema Actores

Informar proveedor
ganador

El sistema envía un mensaje al proveedor ganador, adjuntando la Descripción

orden de compra de las partes solicitadas, si el proveedor da una
respuesta positiva para la orden de compra se pasa a actualizar el
inventario de partes, si no se calcula nuevamente quien es el
proveedor con la siguiente mejor oferta.

Muy alto Impacto

Sistema Actores

Actualizar inventario
de partes

Cuando una subasta se cierra, y se tiene un proveedor ganador, se Descripción

actualiza el inventario con las partes que se piden al proveedor.

Muy alto Impacto

Sistema Actores
4.2.2. Vista lógica:

El siguiente diagrama especifica las diferentes capas del sistema, como los
diferentes componentes que intervendrán en cada una de las capas. Los cuadros
de color azul claro son los diferentes componentes que intervienen en cada una
de las capas especificadas, y las líneas punteadas relaciona cada elemento del
diagrama con los otros elementos que interactúa.

Figura 6. Vista lógica

Se ofrece una descripción detallada de cada uno de los elementos del diagrama:

Capas:

● Presentación: Contiene la parte gráfica con la que interactúa el usuario.

● Integración: Contiene los diferentes elementos que permiten la interacción
entre los diferentes sistemas de información
● Lógica de negocio: Contiene las funcionalidades del núcleo del negocio.
● Datos: Contiene todas las bases de datos.
● Seguridad: Provee todos los elementos que brinden la integridad y
confidencialidad de los datos.
● Sistemas externos: Sistema de Car Advanced y Sistema de inventario.
 Subsistemas:

● Portal: Acceso secundario a las diferentes funcionalidades.

● Integrador: Integra los sistemas externos con el sistema principal.

Sistema:

● Sistema Car Advanced: Sistema principal de la empresa

Módulos:

● Subastas: Funcionalidades asociadas a la gestión de las subastas. Accede a la

información del sistema de inventario para permitir las diferentes ofertas según
las necesidades detectadas. Además suministra información para la generación
de informes.
● Ofertas: Funcionalidades asociadas a la gestión de ofertas. Esta depende del
módulo de subasta para poder tener una oferta en particular.
● Gestión de datos: Funcionalidades para consultar, actualizar, modificar e
insertar datos sobre una estructura específica. Este es llamado por los otros
módulos para acceder a sus funcionalidades.
● Mensajería: Controla el envío de mensajes para el usuario.
● Reportes: Extrae información de diferentes componentes para la generación de
informes que serán enviados al usuario.
● Monitoreo: Vigila constantemente el sistema de Car Advanced para detectar
indisponibilidad del sistema.
● Inventario: Funcionalidades de interacción entre el sistema de Car Advance y
el sistema de Inventarios.

4.2.3. Vista de implementación:

Esta vista está enfocada a los desarrolladores del sistema, en el cual se muestra
la administración que se debe tener sobre el software, a partir de diagrama de
paquetes o en su defecto de componentes (DiMaggio et al., 2012).

La vista de desarrollo se centra en la organización real de los módulos de

software en el ambiente de desarrollo. El software se empaqueta en partes
pequeñas, llamadas bibliotecas de programas o subsistemas, pueden ser
desarrollados por uno o un grupo pequeño de desarrolladores. Los subsistemas
se organizan en una jerarquía de capas, cada una de las cuales brinda una
interfaz estrecha y bien definida hacia las capas superiores.(jboos.org, 2013)

El diseño de arquitectura seleccionado corresponde a una estructura de

aplicación J2EE de alto nivel, donde se especifican claramente todas las
funcionalidades en estructuras especializadas que permiten garantizar un buen
desempeño a partir de mejores prácticas de programación y en especial la Web.
Se presenta entonces el siguiente diagrama a nivel de módulos, utilizando una
variante de la notación de Booch. (SeamFramework.org, 2009; jboos.org, 2013)
Figura 7. Representación vista de implementación
 ● <<JBoss AS>>: Servidor Web para ejecución de aplicaciones.
● <<JSF2>>: Hace referencia a las páginas de Java Server Faces que soporta
RichFaces, y que como tal son las interfaces con las que interactúan los
usuarios finales del sistema. Tales como:
○ OffertPage.jsp, SalePage.jsp, QueriesPage.jsp
● <<SeamFramework>>, compuesta de:
○ SeamContext, que en este caso representa el controlador Servlet a través
del cual se comunican las páginas visuales, además manipula los estados de
los componentes y contextos.
○ SeamComponent, provee el control para los procesos lógicos del negocio
que luego se transmitirán también a los Beans, manipula los servicios.
● <<EJB3>>: Enterprise Java Bean, representa el mapeo de datos relacionales
DAO, manipulación de servicios y controla capa lógica de negocio. Por ejemplo:
○ OffertService, SaleService, OrderPriceService, InventoryService,
InvoiceService.
● <<JPA2>>: Java Persistence API reúne las especificaciones que describen el
manejo de datos relacionales en las aplicaciones.
● <<JAX-WS>>: Provee funcionalidades para exponer y consumir WebServices.
○ Basado en los principios de Arquitectura SOA (Dhingra, 2013).
○ Y teniendo en cuenta el WS-Security.

4.2.4. Vista de procesos:

La siguiente vista está enfocada a los integradores del sistema, en el cual se

muestra los procesos de comunicación que tendrá el sistema, a partir de
diagrama actividad. La notación que usamos para la vista de procesos se
expande de la notación originalmente propuesta por Booch para las tareas de
Ada y se centra solamente en los elementos arquitectónicamente relevantes.

Figura 8. Elementos vista de proceso

 Figura 9. Vista de procesos

1. Primero un empleado de la empresa Car Advanced o el mismo sistema crea

una subasta de una o unas determinadas piezas en particular a partir de las
necesidades que se tengan, esta subasta se publica para que los diferentes
proveedores puedan realizar una oferta que satisfaga las necesidades de la
subasta.
2. Los diferentes proveedores desde sus propios sistemas o desde el portal
pueden realizar sus respectivas ofertas.
3. Luego de un tiempo establecido se selecciona la mejor oferta realizada entre
todos los proveedores.
4. Se genera una orden de compra para la oferta seleccionada, con todas las
características de esta.
5. Se envía por correo electrónico la orden de compra generada al proveedor.
6. El proveedor puede aceptar o rechazar la orden de compra recibida, si ésta es
rechazada, el sistema selecciona la mejor oferta disponible y genera
nuevamente el proceso.
7. Si la orden de compra es aceptada, se envía una un mensaje al sistema de
inventarios de la empresa Car Advance, para que actualice el inventario
disponible según las características de la orden de compra.
 8. Finalmente de cierra la subasta, cambiando su estado e imposibilitando
participar en ella.

4.2.5. Vista de despliegue:

La siguiente vista está enfocada a los ingenieros de redes, en el cual se muestra

la topología del sistema, a partir de diagrama de despliegue.
Mapeando el software al hardware.
La arquitectura física toma en cuenta primeramente los requisitos no funcionales
del sistema. El software se ejecuta sobre una red de computadores o nodos de
procesamiento. Los diferentes elementos identificados –redes, procesos, tareas y
objetos– requieren ser mapeados sobre los nodos. Por lo tanto, el mapeo del
software en los nodos requiere ser altamente flexible y tener un impacto mínimo
sobre el código fuente.

Como se va a observar en el siguiente diagrama, se cuenta entonces con:

● Accesos a los sistemas tanto de forma interna en las redes del cliente, como de
forma externa (Internet) para todos los usuarios en general. Así como la propia
comunicación interna que van a llevar los diferentes sistemas de integración.
● Se provee un sistema de almacenamiento completo tanto por archivos físicos
en sistema como por Bases de Datos.
● Para las comunicaciones y accesos entre los diferentes empaquetamientos de
módulos se tiene la disposición de Balanceadores de Carga, que permitan la
denegación o aceptación de los servicios, o redirección a los diferentes
servidores, en caso de que se encuentren ocupados unos u otros. Como es el
caso del acceso de los usuario al portal, comunicación entre el Bus de Servicios
y Jboss, o la solicitud de los sistemas externos al consumo de utilidades.
● Como medida de aseguramiento también se cuenta con un cortafuego (Firewall)
que permita solo accesos autorizados.
● Para ingreso tanto al portal como al sistema web, se tiene redundancia de
nodos servidores (inicialmente serán 2).
● En cuanto al Servidor Web de aplicaciones, idealmente tendrá conectado un
computador para administración remota.
● Se dispone de un módulo empaquetado tanto de los Bus de servicios, para
gestionar aquellas funcionalidades (servicios) que proporcionan los aplicativos
web y usan los sistemas de integración. Y BPEL para la definición de los
procesos de negocio de la compañía dentro de estas funcionalidades.
Figura 10. Vista de Despliegue
5. TÁCTICAS, ESTRATEGIAS Y PATRONES DE ARQUITECTURA

Método ADD (Attribute Driven Design)

Es un método para diseñar Arquitectura de Software en donde tanto requerimientos
funcionales y de calidad estén reunidos. Define una Arquitectura de software basada en
descomposición sobre los atributos de calidad.

El ADD sigue un proceso de diseño recursivo, que descompone un sistema o elementos

de un sistema para aplicar tácticas de arquitectura y patrones que satisfagan este
método. Además este modelo utiliza esencialmente un "Plan do, and check". (Wojcik et
al., 2006)

Command Query Responsability Segregation

CQRS es simplemente la creación de dos objetos donde antes había sólo uno. La
separación se produce basándose en que si los métodos son un comando o una
consulta. Un comando es cualquier método que muta el estado y una consulta es
cualquier método que devuelve un valor.

Segrega estrictamente la responsabilidad de controlar la entrada de comandos en un

sistema autónomo de la responsabilidad de manejar el libre efecto de lado,
consulta/lectura en el mismo sistema. En consecuencia, el desacoplamiento permite
cualquier número de consulta/lectura homogéneo o heterogéneo. En términos simples,
tú no haces consultas de servicio a través del mismo módulo de servicio que se procesa
a través de comandos (Microsoft, 2013).

Ayuda principalmente con la Escalabilidad.

Product Line Architecture (PLA)

El PLA en su nivel más fundamental es una arquitectura prescriptiva y bien definida que
proporciona la variabilidad a través de los límites que se proporcionan en forma de
reglas o restricciones. Está construido bajo un framework con enfoque a garantizar
implementaciones consistentes, repetitivas y soportables. Hay que imaginarlo como un
"diseño dirigido" que puede ser aprovechado para reducir la complejidad y aumentar la
calidad de la entrega. (Isom, 2013a; 2013b)

Permite precisamente mejorar la calidad del sistema.

6. COMPONENTES COTS

En los últimos años se ha visto un aumento en el uso de componentes comerciales en

prácticas de reutilización de software. Concretamente, estos componentes comerciales
comúnmente conocidos con el nombre de COTS ( Commercial Off The Shelf ) están
siendo considerados con mayor frecuencia para la construcción de sistemas complejos,
distribuidos y abiertos.(Blogdiario, 2007)

Para la elaboración de estos sistemas los ingenieros utilizan metodologías, procesos y

técnicas de desarrollo basados en componentes (DSBC).
 Los componentes de COTS se construyen mediante la integración a una gran escala de
componentes adquiridos a terceras partes. Estas actividades de desarrollo afectan tanto
a la organización encargada de hacer la adquisición como a la organización encargada
de los componentes COTS.

Según requerimientos para el sistema, se tendrá en cuenta la integración al Sistema de

Inventario, ya que lo posee la compañía y solicita realizar algunos tipos de comunicación
para consulta/escritura en el mismo. Además se opta por integrar un sistema de Pixeles
como Google Analytics E-commerce que permite a la compañía realizar seguimientos
detallados, estadísticos y en tiempo real sobre los sucesos de la compañía en ventas,
visitas, entre otros.

7. SUPUESTOS

En el proceso de selección y definición de la arquitectura para el proyecto presentado,

se tuvieron en cuenta los siguientes supuestos, que de una u otra manera, influenciaron
algunas características del modelo final presentado. Los supuestos mencionados son:

● El problema de la disminución de ventas que se expone en el caso de estudio no es

nuevo, hace aproximadamente 3 años se ha estado incrementado, a tal punto que ven
muy necesario la solución tecnológica de una manera inmediata.
● Buscando una mayor portabilidad y usabilidad del sistema, este tendrá una resolución
estándar, buscando una compatibilidad con dispositivos móviles.
● El presupuesto con el que cuenta la empresa es limitado, respecto a la envergadura
del proyecto y el poco tiempo que se tiene para desarrollarlo.
● Cuando se envíe una orden de compra, después de que se haya seleccionado un
proveedor ganador, se generará una factura virtual y se envía una alerta, las cuales
estarán encriptadas para una mayor seguridad.
● Buscando minimizar costos, no se actualizará el inventario recién se tenga un
proveedor ganador, para esto se enviará un enlace al proveedor para que acepte
finalmente la propuesta o no, si la acepta se actualiza el inventario, si no se envió la
propuesta al siguiente proveedor con mejor oferta.
 REFERENCIAS

Blogdiario. (2007). Introduccion Ingenieria de Software. Blogdiario. Disponible en:

http://xherrera334.blogspot.es/1193625420/. [Visitada en Noviembre de 2013].
codingthearchitecture. (2013). Understand the architectural drivers. codingthearchitecture.
Disponible en: http://www.codingthearchitecture.com/pages/book/understand-the-
architectural-drivers.html. [Visitada en Noviembre de 2013].
Dhingra S. (2013). REST vs. SOAP: How to choose the best Web service. searchsoa.
Disponible en: http://searchsoa.techtarget.com/tip/REST-vs-SOAP-How-to-choose-
the-best-Web-service. [Visitada en Noviembre de 2013].
DiMaggio L., Conner K., Kumar M., Cunningham T. (2012). JBoss ESB Beginner’s Guide.
Vol. 1.
Isom A. (2013a). Introducing the microsoft product line architecture. blogs.technet.
Disponible en: http://blogs.technet.com/b/pla/archive/2013/04/09/introducing-the-
microsoft-product-line-architecture.aspx. [Visitada en Noviembre de 2013].
Isom A. (2013b). Benefits of using the Product Line Architecture. blogs.technet. Disponible
en: http://blogs.technet.com/b/pla/archive/2013/07/22/benefits-of-using-the-
product-line-architecture.aspx. [Visitada en Noviembre de 2013].
jboos.org. (2013). Geting started guide.Disponible en:
http://docs.jboss.com/riftsaw/2.0.0.Final/gettingstartedguide/html/examples.html.
[Visitada en Noviembre de 2013].
Kruchten P. (2011). Planos Arquitectonicos: El Modelo de “4+1” Vistas de la Arquitectura
del Software. 1.
Microsoft. (2013). Reference 2: Introducing the Command Query Responsibility
Segregation Pattern. Microsoft. Disponible en: http://msdn.microsoft.com/en-
us/library/jj591573.aspx. [Visitada en Noviembre de 2013].
SeamFramework.org. (2009). Seam Moving Forward. [Visitada en Noviembre de 2013].
Wojcik R., Bachmann F., Bass L., Clements P., Merson P., Nord R., Wood B. (2006).
Attribute-Driven Design (ADD), Version 2.0 ed. Institute S.E. Vol. 2. Software
Engineering Institute.