Documento de Sad

Universidaddelos
Andes
SistemadeRequisicionesyrdenesde
Compra(SIROC)
DocumentodeArquitecturadelSistema(SAD)
Nombre del Equipo de Trabajo:

N/A
Nombre de los Integrantes:
Diego Avendao
e-mail: da.avendano33@uniandes.edu.co
Laura Manzur
e-mail: lc.manzur441@uniandes.edu.co
Fabin Morales
e-mail: ff.morales25@uniandes.edu.co
Bogot D.C. 2008
Universidad de los Andes

Arquitectura de Software 2008-2
Sistema de Requisiciones y rdenes de Compra (SIROC)
Versin
Modificado Por
1.0
Laura Manzur
Diego Avendao
Fabin Morales
mircoles, 05 de
noviembre de 2008
1.1
Laura Manzur
Diego Avendao
Fabin Morales
Laura Manzur
Diego Avendao
Fabin Morales
Laura Manzur
Diego Avendao
sbado, 08 de noviembre
de 2008
2.0
2.1
Fecha
Comentarios
Creacin del documento de
Arquitectura del sistema
Perspectivas de calidad y
Escenarios de calidad
Diagramas
Puntos de vista de informacin
Escenarios de calidad
jueves, 27 de noviembre
de 2008
Arquitectura SOA
Lunes, 01 de Diciembre
de 2008
Blueprint SOA
Relaciones entre Puntos de Vista
ltima actualizacin: martes, 20 de enero de 2009

TabladeContenido
I. Lista de Figuras ..........................................................................................6
II.
Lista de Tablas ........................................................................................7
1. Contexto ....................................................................................................8
1.1. Problemas a Resolver............................................................................8
1.1.1. Descripcin General del Sistema a Desarrollar...................................8
1.1.2. Objetivos .......................................................................................8
1.2. Fundamento de la Solucin ...................................................................9
1.2.1. Aproximaciones Arquitecturales .......................................................9
1.2.2. Anlisis de Resultados...................................................................11
1.2.3. Cubrimiento de Requerimientos .....................................................11
2. Stakeholders ............................................................................................15
3. Atributos de Calidad..................................................................................20
3.1. Perspectivas .......................................................................................20
3.1.1. Seguridad ....................................................................................20
3.1.2. Usabilidad ....................................................................................21
3.1.3. Internacionalidad..........................................................................23
3.1.4. Evolucin .....................................................................................24
3.1.5. Portabilidad..................................................................................25
3.1.6. Disponibilidad y Recuperabilidad ....................................................26
3.1.7. Localizacin..................................................................................27
3.1.8. Desempeo y Escalabilidad............................................................28
3.2. Escenarios de Calidad .........................................................................29
3.2.1. Concurrencia Cantidad de accesos concurrentes...........................30
3.2.2. Disponibilidad y Recuperabilidad Tiempo de funcionamiento del
backup 31
3.2.3. Disponibilidad y Recuperabilidad Acceso a la Base de Datos ..........32
3.2.4. Funcionalidad Reportes Gerenciales ............................................33

3.2.5. Desempeo y Escalabilidad Tiempo de Sincronizacin...................35

3.2.6. Desempeo y Escalabilidad Tiempo de Sincronizacin...................35
3.2.7. Desempeo y Escalabilidad Sincronizacin de Informacin............36
3.2.8. Seguridad Autenticacin .............................................................37
3.2.9. Seguridad Autorizacin...............................................................38
3.2.10.
Usabilidad Buena Curva de Aprendizaje ....................................39
4. Puntos de Vista.........................................................................................41
4.1. Punto de Vista de Despliegue ..............................................................41
4.1.1. Descripcin ..................................................................................41
4.1.2. Modelos de Plataforma de Ejecucin y de Red ................................42
4.1.3. Modelos de Dependencia Tecnolgica ............................................43
4.2. Punto de Vista Funcional .....................................................................43
4.2.1. Descripcin ..................................................................................43
4.2.2. Modelos de Estructura Funcional....................................................44
4.2.3. Modelo de Procesos de Negocio.....................................................46
4.3. Punto de Vista de Informacin.............................................................47
4.3.1. Descripcin ..................................................................................47
4.3.2. Modelos de Estructuras Estticas de Datos .....................................47
4.3.3. Modelos de Flujo de Informacin ...................................................49
4.3.3.1. Modelo de Flujo de Informacin de una Requisicin .....................50
4.3.3.2. Modelo de Flujo de Informacin de una rden de Compra............51
4.3.4. Modelo de Propiedad de los Datos .................................................51
4.3.5. Modelos de Ciclo de Vida de Informacin........................................52
4.3.5.1. Modelo de Ciclo de Vida de una Requisicin.................................52
4.3.5.2. Modelo de Ciclo de Vida de una rden de Compra .......................53
4.3.5.3. Modelo de Ciclo de Vida de una Cotizacin ..................................53
4.3.5.4. Modelo de Ciclo de Vida de un Usuario........................................53
4.4. Punto de Vista de Concurrencia ...........................................................54
4.4.1. Descripcin ..................................................................................54

4.4.2. Modelo de concurrencia ................................................................54

4.4.3. Modelos de estado........................................................................55
4.4.3.1. Servicios Inicio ..........................................................................55
4.4.3.2. Servicios Requisicin..................................................................55
4.4.3.3. Servicios aprobacin ..................................................................56
4.4.3.4. Servicios catlogo ......................................................................56
4.4.3.5. Servicios compra .......................................................................57
4.4.3.6. Servicios seguridad ....................................................................57
4.4.3.7. Data services.............................................................................58
3.1. Relaciones entre los Puntos de Vista ....................................................58
4. Plan de Pruebas........................................................................................63
5. Evaluacin de la Arquitectura.....................................................................67
5.1. rbol de Atributos de Calidad...............................................................67
5.2. Anlisis de Escenario de Calidad ..........................................................68
6. Arquitectura SOA (Service Oriented Architecture) ........................................69
6.1. Portafolio de Servicios .........................................................................69
6.2. Modelo de Atributos ............................................................................70
6.3. Modelo de Taxonoma de Servicios.......................................................71
6.4. Matrices de Granularidad.....................................................................76
6.5. Blueprint SOA.....................................................................................77
7. Referencias Bibliogrficas ..........................................................................78
8. Directorio .................................................................................................79
8.1. Glosario de Trminos ..........................................................................79
8.2. Acrnimos ..........................................................................................80

I.
ListadeFiguras
ILUSTRACIN 1-DIAGRAMA DE CASOS DE USO ............................................................12

ILUSTRACIN 2-ORGANIGRAMA DE LA EMPRESA ..........................................................16
ILUSTRACIN 3-DIAGRAMA DE DESPLIEGUE ...............................................................42
ILUSTRACIN 4-DIAGRAMA CONCEPTUAL ..................................................................44
ILUSTRACIN 5-DIAGRAMA DE COMPONENTES ............................................................45
ILUSTRACIN 6-DIAGRAMA DE PROCESOS DE NEGOCIO .................................................46
ILUSTRACIN 7-DIAGRAMA DE ESTRUCTURAS ESTTICAS ...............................................47
ILUSTRACIN 8-FLUJO INFORMACIN REQUISICIN .....................................................50
ILUSTRACIN 9-FLUJO INFORMACIN RDEN DE COMPRA..............................................51
ILUSTRACIN 10-CICLO DE VIDA REQUISICIN ...........................................................52
ILUSTRACIN 11-CICLO DE VIDA RDEN DE COMPRA ...................................................53
ILUSTRACIN 12-CICLO DE VIDA COTIZACIN ............................................................53
ILUSTRACIN 13-CICLO DE VIDA USUARIO ................................................................53
ILUSTRACIN 14 - MODELO DE CONCURRENCIA ...........................................................54
ILUSTRACIN 15-RBOL DE ESCENARIOS DE CALIDAD ..................................................67
ILUSTRACIN 16-PORTAFOLIO DE SERVICIOS SOA ......................................................69
ILUSTRACIN 17-MODELO DE ATRIBUTOS .................................................................70
ILUSTRACIN 18-TAXONOMA DE ESTADSTICAS Y CONTROL DE OPERACIONES ....................71
ILUSTRACIN 19-TAXONOMA DE CONTROL DE OPERACIONES Y NOTIFICACIONES.................71
ILUSTRACIN 20-TAXONOMA DE CONCURRENCIA Y CONTROL DE OPERACIONES ..................71
ILUSTRACIN 21-TAXONOMA DE DISPONIBILIDAD Y CONTROL DE OPERACIONES .................72
ILUSTRACIN 22-TAXONOMA DE SEGURIDAD Y CONTROL DE OPERACIONES .......................72
ILUSTRACIN 23-TAXONOMA DE DISPONIBILIDAD, SEGURIDAD Y CONCURRENCIA................73
ILUSTRACIN 24-TAXONOMA DE SEGURIDAD, CONTROL DE OPERACIONES Y NOTIFICACIONES 74
ILUSTRACIN 25-TAXONOMA DE ESTADSTICAS, CONTROL DE OPERACIONES Y SEGURIDAD ....75
ILUSTRACIN 26-MATRIZ DE GRANULARIDAD .............................................................76
ILUSTRACIN 27-BLUEPRINT SOA ..........................................................................77

II. ListadeTablas
TABLA 1-CASOS DE USO DEL SISTEMA ......................................................................13
TABLA 2-LISTADO DE LOS STAKEHOLDERS .................................................................17
TABLA 3-STAKEHOLDERS Y CONCERNS ......................................................................17
TABLA 4-STAKEHOLDERS Y VIEWPOINTS ...................................................................18
TABLA 5-DEPENDENCIAS TECNOLGICAS ...................................................................43
TABLA 6-RELACIONES DE LA INFORMACIN ESTTICA ...................................................48
TABLA 7-PERMISOS DE LOS USUARIOS Y ELEMENTOS SOBRE LA INFORMACIN .....................51
TABLA 8-COMPONENTES - VISTA DESPLIEGUE ............................................................60
TABLA 9-COMPARACIN FUNCIONAL-VISTA ...............................................................61
TABLA 10-PRUEBA 1: VALIDACIN DE UN USUARIO ......................................................63
TABLA 11-PRUEBA 2: COTIZAR UN ITEM ...................................................................64
TABLA 12-PRUEBA 3: AGREGAR UN PRODUCTO AL CATLOGO..........................................65
TABLA 13-ANLISIS ESCENARIO DE CALIDAD .............................................................68
TABLA 14-GLOSARIO DE TRMINOS .........................................................................79
TABLA 15ACRNIMOS ........................................................................................80

1. Contexto
1.1.
ProblemasaResolver
Se necesita desarrollar una aplicacin que permita hacer requisiciones por

parte de funcionarios en una organizacin de bienes que se necesiten. Se debe
poder autorizar o rechazar una solicitud y en caso de ser autorizada se debe
poder solicitar cotizaciones de los bienes requeridos a distintos proveedores.
Eventualmente la aplicacin debe permitir efectuar una orden de compra,
llevar registro de los bienes adquiridos, cerrar una orden con su respectiva
facturacin.
1.1.1. DescripcinGeneraldelSistemaa
Desarrollar
Se pretende realizar una aplicacin que permita expedir formularios
requisicin de materiales para los funcionarios de un PYME. La
aplicacin debe poder accederse va web y permitir, dependiendo de
las autorizaciones correspondientes, realizar requisiciones, rdenes de
compra, reportes gerenciales, logs de operaciones, entre otros.
1.1.2. Objetivos
Los objetivos sobre los cuales se bas la arquitectura aqu presentada
para la aplicacin SIROC son los siguientes:
Garantizar la seguridad del sistema.
Generar reportes completos necesarios en un tiempo
conveniente.
Permitir escalabilidad.

1.2.
FundamentodelaSolucin
En este documento, presentamos de una forma exhaustiva la arquitectura del

sistema que consideramos ms apropiada para resolver los requerimientos del
cliente en cuanto a la aplicacin a desarrollar. A travs de los viewpoints
establecidos a continuacin segn los stakeholders identificados, podremos
notar que se propone una arquitectura adecuada para los atributos de calidad
planteados por el cliente.
Parte de la solucin fue lograr balances aproximados a los requerimientos
funcionales identificados en las primeras etapas del proceso de desarrollo de la
arquitectura del sistema, en conjunto con los stakeholders identificados.
En sta seccin del presente documento, tambin podemos apreciar los
requerimientos funcionales de la aplicacin, alrededor de los cuales tambin
gira, tanto el diseo como la arquitectura de la solucin.
1.2.1. AproximacionesArquitecturales
La arquitectura escogida en el presente documento pretende optimizar los
atributos de calidad presentados por los stakeholders para la correcta
ejecucin de la aplicacin segn los concerns planteados posteriormente
en el presente documento.
Los puntos de vista sobre los cuales se desea enfatizar son los puntos de
vista de Despliegue, Funcional y de Informacin, dado que se considera
que son los ms crticos en los intereses de los stakeholders.
El estilo arquitectural escogido en este documento como candidato es un
artculo arquitectural de tres (3) niveles dado que presenta un alto

grado de seguridad al separar los componentes de presentacin, lgica

de negocio y persistencia. Adicionalmente, presenta facilidades de
desempeo en el sistema por la fcil localizacin de los elementos que
pertenecen al mismo nivel. Adicionalmente, facilita la funcin de
desarrollo al independizar tres (3) funcionalidades individuales de una
aplicacin JEE.
En el punto de vista de despliegue se pretende recalcar el inters del
stakeholder director de operaciones de tener un nodo de respaldo para
posibles cadas del sistema. Adicionalmente, se tiene en cuenta la
necesidad de tener una alta concurrencia en el sistema dado el
crecimiento exponencial de la empresa y las altas solicitudes de los
funcionarios al final del mes. Tambin se busca tener en cuenta los
requisitos de seguridad de los altos funcionarios del empresa por lo cual
se hace especial nfasis en la separacin de nodos fsicos de la
aplicacin.
En el punto de vista funcional se busca mostrar las relaciones tanto
estticas con dinmicas de los elementos funcionales de la aplicacin.
Las relaciones presentadas buscan el mximo rendimiento de la
aplicacin el cual exalta el atributo de calidad de desempeo y asimismo
optimizando la seguridad del sistema por medio de interfaces de
servicios entre los principales componentes.
En el punto de vista de informacin se desea mostrar los ciclos de vida
de los datos manejados tanto por el sistema como por los usuarios y
sus interacciones con la aplicacin en ciertos puntos de la ejecucin.
Tambin se desea presentar los stakeholders y elementos funcionales y
sus correspondientes permisos CRUD sobre los datos y el flujo de los
mismos dentro de la aplicacin misma.
10

1.2.2. AnlisisdeResultados
Esta seccin describe los resultados cuantitativos y cualitativos
obtenidos despus de evaluar la arquitectura del sistema.
1.2.3. CubrimientodeRequerimientos
Analizando el resumen del problema, lo primero que pudimos identificar
son los casos de uso especificados para la aplicacin. A continuacin
podemos observar el diagrama de casos de uso desarrollado para
mostrar los requerimientos funcionales.
Los requerimientos especificados en el diagrama de casos de uso fueron
identificados a partir del contexto en que el se va a utilizar la aplicacin,
y los concerns de cada stakeholder identificado.
11

Ilustracin 1-Diagrama de Casos de Uso
En el previo diagrama se presentan las diferentes funcionalidades que

desean presentar los correspondientes stakeholders
Teniendo en cuenta el previo diagrama, se pudo construir la tabla de los
casos de uso, la cual identifica y describe cada requerimiento funcional,
importantes para el desarrollo de la aplicacin.
12

T
Tabla 1-Casos de Uso del Sistema
Caso de Uso
Iniciar Sesin
Descripcin
Cualquier funcionario del sistema puede
ingresar con su login y contrasea a la
aplicacin.
Diligenciar formato de
Cualquier funcionario del sistema puede
requisicin
expedir una requisicin para materiales o

insumos.
Ingresar tem de compra al
Cualquier funcionario que requiera un
catalogo de la empresa
insumo, el cual no se encuentre en el

catlogo de la empresa, puede ingresarlo
al sistema y asignarle un cdigo nico.
Objetar un formulario de
El director de rea puede objetar el monto
requisicin
y el propsito de la compra. El formulario

se retorna al funcionario que lo solicit.
Aprobar un formulario de
El director de rea puede aprobar un
requisicin
formulario de requisicin, el cual se enva

al departamento de compras.
Solicitar cotizaciones a
Se solicitan 3 cotizaciones a proveedores
proveedores
por cada tem en los formularios de

requisicin.
Generar orden de compra
Una vez el proveedor es seleccionado se

diligencia una orden de compra llenando el
formulario correspondiente que se enva
va mail.
Registrar entregas de
El proveedor seleccionado puede hacer
13

bienes en el inventario
entregas parciales o totales de un bien.

Cada entrega se registra ingresando la
cantidad de bienes en el inventario y se
actualiza la cantidad a entregar.
Cerrar orden de compra
Una vez la entrega se han entregado todos

los bienes solicitados la orden de compra
se cierra, y se procede al pago de la
factura.
Generar Reportes
Se consultan estadsticas referentes al
Gerenciales
proceso de requisiciones tales como total

de compras, bienes ms comprados,
proveedor al que ms se hacen compras,
tiempos de entrega etc.
Informar Solicitudes de
Luego de que una compra sea aceptada se
compra
debe informar el evento al director del

departamento de compras.
Notificar Cambio de estado
Notificar luego de cada evento importante

(seleccin de proveedor, generacin de
orden de compra, clausura de compra
etc.) al director de rea.
14
Generacin de Registro
Debern generarse registros o logs de las
Operaciones
operaciones realizadas en el sistema.

2. Stakeholders
Esta seccin presenta una lista de los stakeholders involucrados en el
proyecto. Para cada uno de ellos, se deben listar los concerns que van a ser
tenidos en cuenta en el documento de arquitectura. Esta informacin se presenta
en forma de matriz, donde las filas representan los stakeholders y las columnas
los concerns. Cada celda determina el grado de relevancia del concern para el
stakeholder (Tabla 2). Finalmente, basados en los concerns relevantes a cada
stakeholder se dermina 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
administradores.
Customer
Project manager
Application software
Communications
developers
Infrastructure
software developers
End users
Application system
engineers
Application
hardware engineers
engineers
Chief Engineer/Chief
Scientist
Program
management
System and software
integration and test
External
organizations
Operational system
managers
Trainers
Maintainers
Auditors
Security engineers
and certifiers
engineers
Safety engineers and
certifiers
15

Ilustracin 2-Organigrama de la Empresa
16

Tabla 2-Listado de los Stakeholders
Stakeholder
Descripcin
Funcionario
Un funcionario es cualquier empleado de la empresa, el

cual puede diligencias formularios de requisicin.
Director de rea
Encargados de reas especficas de la empresa. Los jefes

inmediatos de los funcionarios, los cuales aprueban los
formularios de requisicin.
Director de Compras
Encargado de realizar cotizaciones de los pedidos

autorizados y contactar a los proveedores para pedir
insumos.
Gerente
Cabeza
principal
de
la
empresa.
Recibe
reportes
gerenciales.
Director de Sistemas
Encargado de los sistemas tecnolgicos de la empresa.

Encargado de conocer los requerimientos de hardware y
software necesarios por la empresa.
Director de
Encargado de las sucursales de la empresa. Administra
Operaciones
los nodos de operaciones.
Desarrolladores
Encargado de disear la arquitectura de la aplicacin y

desarrollar
sus
funcionalidades,
atendiendo
las
especificaciones de los stakeholders y sus intereses.

Tabla 3-Stakeholders y Concerns
Stakeholder
Funcionario
Concerns
Ingresar de forma fcil y rpida al sistema.
Uso intuitivo y sencillo de la aplicacin.
Diligenciar requisicin de bienes.
Conocer resultado de requisicin.
Director de rea
Ser notificados del cambio de estado de una
17

solicitud de compra.
Ser el nico autorizado a acceder a esta
informacin y seguridad de la aplicacin en
particular para evitar compras no autorizadas.
Usabilidad de la aplicacin.
Ingresar de forma fcil, rpida y electrnicamente.
Director de Compras

Conocer solicitudes de compra aceptadas en
menos de dos minutos.
Gerente

Tener reportes gerenciales disponibles en todo
momento.
Conocer los requerimientos de hardware y

software.
Procesamiento de una solicitud en corto tiempo y
soporte de alto nivel de concurrencia.
Tener disponible registro de todas las operaciones
realizadas.
Director de
Disponibilidad de la aplicacin.
Operaciones
Acceso rpido al nodo auxiliar.
Desarrolladores
Conocer el funcionamiento de la aplicacin.

Conocer los requerimientos funcionales y no
funcionales.
Conocer la arquitectura de la aplicacin.
Tabla 4-Stakeholders y Viewpoints
18
Stakeholder
Viewpoint
Funcionario
Operational Viewpoint

Director de rea
Operational Viewpoint, Information Viewpoint
Director de Compras
Operational Viewpoint, Functional Viewpoint
Gerente
Operational Viewpoint
Functional Viewpoint, Deployment Viewpoint,

Concurrency Viewpoint, Information Viewpoint
Director de
Deployment Viewpoint, Information Viewpoint
Operaciones
Desarrolladores
Development Viewpoint
19

3. AtributosdeCalidad
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.
Los atributos de calidad son definidos como caractersticas de un
componente o sistema. El objetivo de esta seccin es presentar una
evaluacin de los atributos para un diseo apropiado de los mismos en el
desarrollo y diseo de la arquitectura de la aplicacin.
Los escenarios de calidad pretenden evidenciar los atributos de calidad
correspondientes en situaciones posibles.
3.1.1. Seguridad
3.1.1.1. CalidadDeseada
La aplicacin ofrece un alto nivel de seguridad en cuanto al
acceso a informacin importante para la empresa y la
ejecucin correcta del proceso de requisiciones.
3.1.1.2. Aplicabilidad
Esta perspectiva, presente en todos los puntos de vista,
afectar en particular los puntos de vista de despliegue y de
informacin dado que se debe controlar el acceso a la base
de datos, restringir la funcionalidad a algunos usuarios y
requiere un manejo de la informacin delicado en la base de
datos.
20

3.1.1.3. Concerns
Se pretende evitar especficamente compras no autorizadas
y el mal uso del software, permitir el acceso de la
informacin contenida en los reportes nicamente a los
usuarios autorizados y garantizar la disponibilidad del
sistema.
3.1.1.4. Actividades
Identificar puntos dbiles de la arquitectura.
Identificar mecanismos para ayudar a minimizar las
fallas y violaciones del sistemas tales como firewalls,
sistema de autenticacin y autorizacin, uso de vistas
en la base de datos, etc.
Establecer modulo de backup.
3.1.1.5. Tcticas
Usar
principios
herramientas
conocidos
en
seguridad.
Permitir una correcta identificacin y autenticacin.
Ofrecer mecanismo de auditoras.
Asegurar
integridad
de
la
informacin
usar
mecanismos de recuperacin.
3.1.2. Usabilidad
Para que la aplicacin en efecto ayude a agilizar el proceso
de requisiciones la interaccin con la aplicacin debe ser
fcil, en particular debe poder aprender a usarla de manera
intuitiva.
21

Esta perspectiva afectar el punto de vista funcional puesto
que aqu se definirn las interfaces externas y su interaccin
con las dems interfaces. Por otro lado afectar en mayor
medida el punto de vista de informacin, la forma como se le
presenta esta al usuario y su calidad son claves para lograr
un alto nivel de calidad en la usabilidad.
3.1.2.3. Concerns
Manejo intuitivo de la aplicacin y facilidad de aprendizaje,
desplegar informacin de manera agradable y desplegar la
informacin pertinente para permitir al usuario tomar accin,
ofrecer las opciones que permitan una fcil navegacin de la
aplicacin.
Identificar touchpoints.
Identificar funcionalidades importantes para el usuario
que deben proveerse desde la interfaz.
Identificar diferentes tipos de usuario y entender las
capacidades y restricciones de cada uno.
Entender los procesos de negocio.
3.1.2.5. Tcticas
Usar lenguaje amigable, no muy tcnico e conos
estndar.
Separacin de la implementacin de la interfaz de la

lgica de negocio.
22

3.1.3. Internacionalidad
La aplicacin no es exclusiva de un lenguaje particular.
Asegura la universalidad en base a uno de los idiomas
utilizados: ingls.
Esta perspectiva afectar el punto de vista funcional, dado
que la interaccin del usuario con la aplicacin se ver
determinada por la facilidad de uso de la misma por el
usuario, sin importar el idioma hablado por el usuario
mismo.
3.1.3.3. Concerns
Facilitar la interaccin del usuario con la aplicacin sin
discriminacin de idioma o lenguaje. Permitir la universalidad
de la aplicacin.
Identificar los elementos claves de la interfaz de
usuario que tienen dependencias de idioma.
Identificar palabras clave de fcil entendimiento para

el usuario e implementarlas.
3.1.3.5. Tcticas
Definir mecanismo de desacoplamiento del idioma en
la interfaz de usuario.
Definir plantillas de idiomas para la usabilidad del
usuario.
23

3.1.4. Evolucin
La aplicacin deber permitir la modificacin de alguno de
sus componentes sin implicar mayores repercusiones en la
arquitectura que presenta y en un tiempo considerablemente
corto. Si se llegase a necesitar modificar alguno de los
componentes de la aplicacin, las nuevas versiones de stos
deben respetar las interfaces propuestas.
que la modificacin de los componentes afecta el uso de las
interfaces definidas y vara las responsabilidades de la nueva
versin del componente. Tambin se ver afectado el punto
de vista de informacin, dado que el flujo de la informacin
y el manejo de la misma pueden variar con los cambios de
los componentes. El punto de vista de desarrollo es clave en
esta
perspectiva
dado
que
afecta
directamente
al
desarrollador.
3.1.4.3. Concerns
Facilitar la modificacin de los componentes de la aplicacin
sin repercusiones en otros atributos de calidad y la aplicacin
misma, y en los tiempos de respuesta y de modificacin.
Identificar los posibles cambios a realizar en los
componentes de la aplicacin.
Analizar el impacto que los posibles cambios pueden
24
tener sobre la aplicacin.


3.1.4.5. Tcticas
Separacin de dependencias entre componentes por
medio
de
interfaces
definidas
por
servicios
especficos.
Creacin de componentes segn agrupacin que

permita la evolucin de la aplicacin.
3.1.5. Portabilidad
La aplicacin permitir su uso sin importar las dependencias
tecnolgicas del usuario dada su ubicacin en la red y su
nico requerimiento tecnolgico: un web browser.
Esta perspectiva afecta el punto de vista de despliegue dado
que hay una dependencia tecnolgica del usuario.
3.1.5.3. Concerns
Permitir que todos los usuarios puedan acceder a la
aplicacin desde sus propias mquinas, sin requerir de
instalaciones especiales o tecnologas especficas.
Utilizar
tecnologas
de
desarrollo
que
sean
independientes de las tecnologas para usar la

aplicacin tal como jsp.
Emplear pruebas en diferentes ambientes de uso para

verificar la correcta ejecucin de la aplicacin.
25

3.1.5.5. Tcticas
Identificar los componentes que se deben usar y que
sean independientes de las tecnologas necesarias
para poder hacer uso de la aplicacin.
3.1.6. DisponibilidadyRecuperabilidad
Se desea asegurar durante la mayor parte del tiempo la
disponibilidad y accesibilidad al sistema y poder restaurar el
sistema en caso de complicacin o mantenimiento en corto
tiempo.
Los principales puntos de vista que se vern afectados por
este atributo son el punto de vista operacional, dado que es
la forma como el sistema ser operado y administrado que
se puede mantener disponible en cualquier momento pueden
comprometer la disponibilidad; y el punto de visto de
concurrencia,
dado
que
los
niveles
de
concurrencia
demasiado altos pueden afectar la disponibilidad hasta el

punto de hacer colapsar el sistema.
3.1.6.3. Concerns
Tiempo que el sistema se mantiene operacional, habilidad de
recuperacin ente fallas e inconvenientes.
Implementar pruebas unitarias, de aceptacin, de
26
sistema, y de integracin para identificar posibles

fallas
del
sistema
que
puedan
afectar
su
disponibilidad.
Establecer modulo de respaldo en caso de falla.
3.1.6.5. Tcticas
Identificar agentes que amenacen la integridad del
sistema. Usar protocolos de recuperacin.
3.1.7. Localizacin
La aplicacin debe poder ejecutarse con igual desempeo y
concurrencia sin importar la localizacin fsica de los
servidores que la contienen, y la localizacin fsica de la
persona que est haciendo uso de la misma.
Esta perspectiva afectar el punto de vista de despliegue y
de concurrencia, dado que implica tener en cuenta los
protocolos que se van a emplear, las redes que se van a
utilizar y la capacidad de los buses de comunicacin; as
como la escalabilidad de las bases de datos sobre las cuales
se va a tener la informacin.
3.1.7.3. Concerns
Tener tiempos de respuesta rpidos independientes de la
ubicacin del usuario en relacin con la ubicacin fsica de la
aplicacin.
27

Implementar
protocolos
de
comunicacin
que
permitan un desempeo equivalente en cualquier

caso.
Escoger las redes adecuadas para el uso efectivo de
la aplicacin.
3.1.7.5. Tcticas
Identificar protocolos y redes adecuados para la
ejecucin correcta y efectiva de la aplicacin.
3.1.8. DesempeoyEscalabilidad
La aplicacin debe poder soportar un nivel de concurrencia
relativamente alto sin que esto afecte dramticamente sus
tiempos de respuesta o disponibilidad. Debe por otra parte
permitirse la evolucin del sistema suponiendo que se
tendrn cada vez mas accesos concurrentes y se deber
soportar una carga cada vez ms grande.
que el buen desempeo del sistema supone una mejor
interaccin con este, y genera confiabilidad; el punto de
vista
de
concurrencia,
dado
que
la
estructura
de
concurrencia del sistema debe poner soportar una carga

grande de accesos concurrentes y se deber poder modificar
a medida que evoluciona; y el punto de vista de despliegue,
dado que las especificaciones de los elementos hardware
28

que se escojan y los medios de comunicacin de los

diferentes mdulos afectan el desempeo del sistema.
3.1.8.3. Concerns
Tiempos de respuesta, soporte para ciento cincuenta (150) o
ms accesos concurrentes al sistema, crecimiento de la
compaa.
Identificar
puntos
crticos
de
desempeo
como
tiempos de respuesta, evaluar la tasa de accesos

estimados para la compaa y su evolucin, evaluar
capacidad de los componentes software y hardware
para soportar niveles altos de concurrencia.
3.1.8.5. Tcticas
Hacer uso de dispositivos de hardware adecuados
dependiendo de los puntos crticos identificados,
asegurar capacidad mayor a la requerida inicialmente,
permitir flexibilidad en el ambiente de desarrollo y la
arquitectura para soportar el crecimiento de la
concurrencia en el tiempo.
3.2. EscenariosdeCalidad
29

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.
El objetivo concreto de los escenarios de calidad es el de detallar en qu
condiciones y de qu manera debe cumplirse un atributo de calidad.
Adicionalmente, permite centrarse en todos los puntos concernientes al
atributo que se busca evidenciar.
3.2.1. ConcurrenciaCantidaddeaccesos
concurrentes
3.2.1.1. Descripcin
Durante un ejecucin bajo condiciones normales, se debe
permitir una cantidad de accesos concurrentes mayor o igual
a ciento cincuenta (150) al final de cada mes en la aplicacin
para realizar consultas bsicas, generacin de requisiciones y
rdenes de compra, y la aprobacin y objecin de las
requisiciones que se registran.
3.2.1.2. Fuente
Todos los usuarios
3.2.1.3. Estimulo
Realizar una requisicin
Consultas de rdenes de compra
Aprobar/Objetar una requisicin
30
Consultar reportes gerenciales

Realizar cotizaciones
Consultar logs
3.2.1.4. Artefacto
Mdulo SIROC
3.2.1.5. Ambiente
Condiciones normales
3.2.1.6. Respuesta
Accesos a la aplicacin y ejecucin correcta de la misma
3.2.1.7. MedidadelaRespuesta
Nmero de accesos concurrentes
3.2.2. DisponibilidadyRecuperabilidadTiempo
defuncionamientodelbackup
3.2.2.1. Descripcin
En caso de falla, el sistema debe pedir confirmacin al
director de operaciones para empezar el funcionamiento del
nodo de backup situado en Barranquilla en menos de un (1)
minuto, garantizando el correcto funcionamiento del sistema
nuevamente.
3.2.2.2. Fuente
Mdulo SIROC y Director de Operaciones
31

3.2.2.3. Estimulo
Poner en funcionamiento la aplicacin nuevamente
3.2.2.4. Artefacto
Mdulo SIROC
3.2.2.5. Ambiente
Nodo central cado
3.2.2.6. Respuesta
Funcionamiento correcto del sistema bajo el segundo nodo
Tiempo de funcionamiento del nodo de backup menor a un
(1) minuto
3.2.3. DisponibilidadyRecuperabilidadAccesoa
laBasedeDatos
3.2.3.1. Descripcin
La base de datos debe permanecer accesible durante el
tiempo en el que se vaya a usar el sistema. Se calcula que
debe ser accesible por lo menos en horarios de oficina 14
horas /6 das /315 das al ao
3.2.3.2. Fuente
Mdulo SIROC
32

3.2.3.3. Estimulo
Acceder a la base de datos
Persistir cambios
Realizacin de consultas a la base de datos
3.2.3.4. Artefacto
Mdulo SIROC
Nivel de persistencia
3.2.3.5. Ambiente
Condiciones normales
3.2.3.6. Respuesta
Funcionamiento normal de la base de datos, consultas y
persistencia efectuada satisfactoriamente durante el tiempo
de uso.
Tiempo de funcionamiento de la base de datos 14/6/315
3.2.4. FuncionalidadReportesGerenciales
3.2.4.1. Descripcin
Se deben generar diferentes reportes indicando entre otras
El total de compra hechas por cada rea o unidad

organizacional por mes
El bien que mas se compra por mes y su valor

discriminado por ciudad
El proveedor al que mas se le han comprado bienes por

categora y ciudad
33

El tiempo promedio de entrega de las bienes solicitados,

discriminados por categora y por ciudad
Adicionalmente como parte de los reportes que se deben

generar se incluyen los registros (Logs) con las operaciones
realizadas por cada funcionario.
3.2.4.2. Fuente
Mdulo SIROC
Base de datos
3.2.4.3. Estimulo
Documentar operaciones realizadas en el sistema
Mantener actualizadas las estadsticas del
funcionamiento de las requisiciones
3.2.4.4. Artefacto
Mdulo SIROC, Base de datos
3.2.4.5. Ambiente
Funcionamiento normal de la aplicacin
3.2.4.6. Respuesta
Reportes gerenciales actualizados luego de efectuar alguna
operacin y documentacin de esta ltima (funcionario que
efectu la operacin, fecha, descripcin de la operacin etc.)
Toda operacin debe estar documentada en los registros y
generar la actualizacin de los reportes luego de ser
efectuada.
34

3.2.5. DesempeoyEscalabilidadTiempode
Sincronizacin
3.2.5.1. Descripcin
Al diligenciarse un formulario de requisicin, el sistema debe
enviar el formulario al director de rea correspondiente, y
ste debe recibir el mismo en menos de dos (2) minutos.
3.2.5.2. Fuente
Funcionario
3.2.5.3. Estimulo
Diligenciamiento de un formulario de requisicin
3.2.5.4. Artefacto
Mdulo SIROC
3.2.5.5. Ambiente
Condiciones Normales
3.2.5.6. Respuesta
Recepcin del formulario de requisicin para aprobacin por
el director de rea
Tiempo de recepcin del formulario de requisicin por el
director de rea correspondiente menor o igual a dos (2)
minutos
3.2.6. DesempeoyEscalabilidadTiempode
Sincronizacin
3.2.6.1. Descripcin
35

Al diligenciarse un formulario de requisicin, el sistema debe

mostrar al funcionario que pas la solicitud el nmero de
radicacin de la requisicin en menos de dos (2) segundos.
3.2.6.2. Fuente
Funcionario
3.2.6.3. Estimulo
3.2.6.4. Artefacto
Mdulo SIROC
3.2.6.5. Ambiente
3.2.6.6. Respuesta
Obtencin del nmero de radicacin del formulario de
requisicin diligenciado.
Tiempo de obtencin del nmero de radicacin menor a dos
(2) segundos.
3.2.7. DesempeoyEscalabilidadSincronizacin
deInformacin
3.2.7.1. Descripcin
Luego de diligenciar un formulario de requisicin, el sistema
debe notificar al funcionario que realiz la diligencia el
estado de la misma y los correspondientes cambios de
36

estado
que
puede
tener
una
requisicin:
pendiente,
aprobada, cotizacin, proveedor, inventario.
3.2.7.2. Fuente
Mdulo SIROC
3.2.7.3. Estimulo
3.2.7.4. Artefacto
Mdulo SIROC
3.2.7.5. Ambiente
3.2.7.6. Respuesta
Notificacin de los cambios de estado de los formularios de
requisicin diligenciados.
Sincronizacin de la informacin correspondiente a los
cambios de estado de los formularios de requisicin.
3.2.8. SeguridadAutenticacin
3.2.8.1. Descripcin
Cuando un usuario accede a la aplicacin (siroc), el sistema
debe buscar al usuario en la base de datos que se encarga
de la administracin y la persistencia de los usuarios. Abra
una tabla en Oracle, esta tabla asociara a cada usuario su
correspondiente clave
3.2.8.2. Fuente
37

Usuario
3.2.8.3. Estimulo
Es necesario administrar y almacenar de una

manera correcta las cuentas de los usuarios
3.2.8.4. Artefacto
Modulo Siroc, base de datos
3.2.8.5. Ambiente
Una persona (usuario) entra a la pagina web, posterior a
eso, el usuario digita un si nombre de usuario y su
correspondiente contrasea. El sistema buscara en la base
de datos la persona y su correspondiente clave.
3.2.8.6. Respuesta
Cada persona ingresara al sistema despus de la
comprobacin en la base de datos.
Si el usuario y/o contrasea no es correcta, no se podr
ingresar al sistema. De lo contrario
3.2.9. SeguridadAutorizacin
3.2.9.1. Descripcin
Cuando un usuario entra a la aplicacin, se le asignara un rol
para la administracin de los roles. Con estos roles se
permitirn algunos permisos y se negaran otros de acuerdo
al tipo de usuario.
3.2.9.2. Fuente
38

Usuario
3.2.9.3. Estimulo
Ser necesario crear administrar permisos para la
aplicacin. Estos se harn mediante los roles
3.2.9.4. Artefacto
Base de datos, Modulo SIROC
3.2.9.5. Ambiente
Luego de la autenticacin de usuario. El sistema asignara un
rol de acuerdo al que tenga asociado el usuario en la base
de datos. Con estos roles se manejaran distintos permisos,
que permitirn una correcta navegacin dentro de la
aplicacin.
3.2.9.6. Respuesta
Cada persona tendr permisos de acuerdo a su rol
El usuario solo podr interactuar con la aplicacin, de
acuerdo a los privilegios que tenga
3.2.10. UsabilidadBuenaCurvadeAprendizaje
3.2.10.1. Descripcin
Todos los usuarios que interacten con la aplicacin,
debern aprender a manejarla de una manera rpida
3.2.10.2. Fuente
Usuario
3.2.10.3. Estimulo
39

Es indispensable que los usuarios se adapten

rpidamente a la aplicacin
3.2.10.4. Artefacto
Capa web
3.2.10.5. Ambiente
La aplicacin es ser desconocida para todos los clientes que
la utilicen. Se buscara la ejecucin correcta de la aplicacin
por parte del usuario
3.2.10.6. Respuesta
Correcta utilizacin de todas las funciones bsicas de la
aplicacin.
El usuario deber aprender las funciones bsicas de la
aplicacin en un tiempo no menor a 2 horas
40

4. PuntosdeVista
Esta seccin presenta los puntos de vista de la arquitectura del sistema: Punto de
vista de Despliegue, Punto de vista Funcional, Punto de vista de Informacin, y
Punto de vista de Concurrencia. Los puntos de vista Operacional y de Desarrollo no
sern tratados en el presente documento.
El objetivo del mismo es presentarle al usuario los diferentes modelos que
responden ante las necesidades de los stakeholders y los atributos de calidad
encontrados en el problema a resolver y planteados a travs de los concerns de los
stakeholders.
4.1. PuntodeVistadeDespliegue
4.1.1. Descripcin
El punto de vista de despliegue describe el ambiente dentro del cual
el sistema ser instalado, incluyendo las dependencias con el
ambiente de ejecucin, y una correspondencia de los elementos de
software con el ambiente de su ejecucin.
41

4.1.2. ModelosdePlataformadeEjecuciny
deRed
Ilustracin 3-Diagrama de Despliegue
En este modelo se ilustra cmo se va a realizar el montaje fsico de la

aplicacin y los nodos de respaldo correspondientes a uno de los
atributos de calidad expresados por uno de los stakeholders.
Adicionalmente, la forma en cmo se distribuyen los componentes
fsicos y la separacin de la aplicacin general con el sistema de
informacin en la Base de Datos aseguran el atributo de calidad
concerniente a la seguridad e integridad de la informacin.
42

4.1.3. ModelosdeDependenciaTecnolgica
Tabla 5-Dependencias Tecnolgicas
Componente
Requiere
Servidor de Aplicaciones
Jboss 4.2.2 AS
Plataforma
J2EE
Localizacin
JNDI
Acceso a Datos
Oracle 10g
Firewall
Conexin WAN
Web Server
Apache Tomcat
4.2. PuntodeVistaFuncional
4.2.1. Descripcin
El punto de vista funcional tiene como principal propsito es
describir los elementos funcionales del sistema, as como sus
principales responsabilidades, interfaces e interacciones.
Este punto de vista afecta algunos modelos de otros puntos de vista
tales como: informacin, concurrencia y despliegue. Este punto de
vista tambin tiene un alto impacto en los atributos de calidad del
sistema, tal como la habilidad de ser modificado, de ser seguro y su
desempeo en ejecucin.
43

4.2.2. ModelosdeEstructuraFuncional
Ilustracin 4-Diagrama Conceptual
Este modelo nos ilustra las relaciones que existen entre los elementos
funcionales de la aplicacin y las interfaces que se prestan los servicios
44

correspondientes a uno o ms elementos funcionales del sistema.
Ilustracin 5-Diagrama de Componentes
Este diagrama expone la distribucin de los diferentes servicios en

componentes que acoplan los elementos funcionales del sistema. Las
interacciones entre los distintos componentes muestran sistemas de
seguridad y manejo de informacin adecuados para las relaciones
que se presentan.
45

4.2.3. ModelodeProcesosdeNegocio
Funcionario
Director rea
Director Compras
Director Sistemas
Gerente General
Ilustracin 6-Diagrama de Procesos de Negocio
El anterior modelo presenta los diferentes procesos que pueden realizar los
stakeholders y como fluye la informacin a travs de los mismos. De esta
manera, se puede evidenciar, igualmente, la navegacin que se puede
seguir en la aplicacin para completar procesos.
46

4.3. PuntodeVistadeInformacin
4.3.1. Descripcin
Describe la forma en que la arquitectura guarda, manipula,
administra y distribuye la informacin. Ilustra el flujo de informacin
durante los procesos de requisiciones y los propietarios de sta.
4.3.2. ModelosdeEstructurasEstticasde
Datos
Ilustracin 7-Diagrama de Estructuras Estticas
A continuacin se pretende presentar las asociaciones establecidas en

el diagrama de estructuras estticas con la intencin de justificar las
decisiones arquitecturales de la cardinalidad y direccionalidad de las
relaciones entre los elementos funcionales de la aplicacin.
47

Tabla 6-Relaciones de la Informacin Esttica
Relacin
Justificacin
Catalogo Categoria
Indica que el catlogo contiene la

informacin clasificada en categoras
Categoria Producto
Indica que las categoras contienen

productos los cuales, a su vez,
conocen la categora a la que
pertenecen
Item Producto
Indica que un tem est asociado al

producto sobre el cual fue creado
Item Cotizacion
Indica que a un tem se le pueden

realizar hasta tres (3) cotizaciones
Proveedor Producto
Indica
que
un
proveedor
tiene
productos, los cuales ofrece a travs

del catlogo
Cotizacion Proveedor
Indica
que
las
cotizaciones
realizadas sobre los tems estn

asociadas al proveedor al cual se le
solicitan
Proveedor
Indica que las rdenes de compra
OrdenCompra
estn asociadas a los proveedores a

los cuales se les solicitan y a su vez,
las rdenes de compra conocen el
proveedor al que pertenecen
OrdenCompra Item
Indica que las rdenes de compra

estn compuestas por tems de
compra
Requisicion Item
48
Indica que las requisiciones estn

compuestas por tems los cuales, a

su vez, conocen la requisicin a la
cual estn asociados
Usuario Requisicion
Indica
que
los
usuarios
tienen
requisiciones las cuales, a su vez,

conocen el usuario al cual estn
asociadas
Usuario Requisicion
Indica que los usuarios que son

directores de rea tiene asociados
una coleccin de requisiciones que
deben aprobar/rechazar
Usuario Log
Indica
que
asociados
los
usuarios
historiales
los
tienen
cuales
tienen registros de las operaciones

realizadas por ese usuario
4.3.3. ModelosdeFlujodeInformacin
Los modelos de flujo de informacin pretenden ilustrar cmo se
puede modelar la informacin que el sistema maneja y cmo fluye
la misma a travs de procesos comunes de la aplicacin.
49

4.3.3.1. ModelodeFlujodeInformacindeuna
Requisicin
Ilustracin 8-Flujo Informacin Requisicin
50

4.3.3.2. ModelodeFlujodeInformacindeuna
rdendeCompra
Ilustracin 9-Flujo Informacin rden de Compra
4.3.4. ModelodePropiedaddelosDatos
El siguiente modelo pretende mostrar los permisos de los usuarios
sobre la informacin que se maneja. Para ello se especifica tambin
quien tiene permisos de creacin (C), lectura (R), modificacin (U) y
eliminacin (D) de la informacin de la aplicacin.
CRU
D
CRU
D
Reportes
Gerencial
es
Historiale
s
Producto
CR
CR
Orden
Compra
CR
CR
Cotizaci
n
Funcionario
Director
Compras
tem
Requisici
n
Tabla 7-Permisos de los Usuarios y Elementos sobre la Informacin
51

Director
Sistemas
Director
Operaciones
Gerente
SIROC
Catlogo
Requisicin
CR
CR
CR
CR
CR
U
CR
CRU
R
CU
CU
CRU
CRU
D
4.3.5. ModelosdeCiclodeVidade
Informacin
Los ciclos de vida de la informacin ayudan a expresar cmo fluyen
los elementos funcionales de gran importancia para el sistema y
cmo son sus procesos de creacin, lectura, modificacin y
eliminacin por los que pasan a lo largo de su ciclo de vida.
4.3.5.1. ModelodeCiclodeVidadeuna
Requisicin
Ilustracin 10-Ciclo de Vida Requisicin
52

4.3.5.2. ModelodeCiclodeVidadeunarden
deCompra
Ilustracin 11-Ciclo de Vida rden de Compra
4.3.5.3. ModelodeCiclodeVidadeuna
Cotizacin
Ilustracin 12-Ciclo de Vida Cotizacin
4.3.5.4. ModelodeCiclodeVidadeunUsuario
Ilustracin 13-Ciclo de Vida Usuario
53

4.4. PuntodeVistadeConcurrencia
4.4.1. Descripcin
Describe la estructura de concurrencia del sistema mapeando los
elementos funcionales a unidades de concurrencia. Muestra las
partes del sistema que se pueden ejecutar concurrentemente y
como esto es controlado y coordinado.
4.4.2. Modelodeconcurrencia
Ilustracin 14 - Modelo de concurrencia
54

4.4.3. Modelosdeestado
4.4.3.1. ServiciosInicio
4.4.3.2. ServiciosRequisicin
55

4.4.3.3. Serviciosaprobacin
4.4.3.4. Servicioscatlogo
56

4.4.3.5. Servicioscompra
4.4.3.6. Serviciosseguridad
57

4.4.3.7. Dataservices
3.1. RelacionesentrelosPuntosdeVista
58

Para poder determinar la arquitectura candidata ms adecuada para

resolver el diseo de una aplicacin, es necesario que todos los puntos de
vista definidos en la misma estn relacionados de manera eficiente y
coherente de tal manera que el producto final este orientado a una
realizacin ms correcta de la solucin del problema.
Cada punto de vista est orientado a ciertos stakeholders especficos para
poder responder a los respectivos concerns de los mismos de manera que
sean lo ms explicativos posibles.
A lo largo del presente documento se desarrollaron los puntos de vista de
Despliegue, Funcional, de Informacin y Concurrencia.
Para el punto de vista de Despliegue, se desarrollo el diagrama de Red, el
cual presenta los componentes fsicos que se van a emplear en la
disposicin de los componentes y los protocolos y firewalls que se van a
usar entre los mismos.
Para el punto de vista Funcional, se desarrollaron dos tipos de modelos:
el
modelo de estructuras funcionales y el modelo de procesos. En el
modelo de estructuras funcionales se plantean los elementos funcionales

de la aplicacin y sus interacciones entre ellos mismos; mientras que en
el modelo de procesos, se plantean los procesos que siguen los usuarios
al interactuar con el sistema.
Para el punto de vista de Informacin, se desarrollaron cuatro tipos de
modelos: el modelo de estructuras estticas, el modelo de ciclo de vida,
el modelo de flujo de informacin, y el modelo de propiedad de los datos.
En el modelo de estructuras estticas se plantean las interacciones entre
los elementos que se persisten del sistema; en el modelo de ciclo de vida
59

se plantean los ciclos de vida de los elementos funcionales de la

aplicacin; en el modelo de flujo de informacin se plantean las diferentes
operaciones que se realizan sobre los elementos funcionales del sistema,
los stakeholders que intervienen en el proceso, y cmo se administra la
informacin de los mismos; mientras que en el modelo de propiedad de
los datos se plantean las propiedades CRUD de los elementos y los
diferentes permisos que tienen stakeholders sobre ellos.
Finalmente, para el punto de vista de Concurrencia se desarrollaron dos
tipos de modelos: el modelo de concurrencia y el modelo de estado. En el
modelo de concurrencia se plantean las interacciones de los usuarios con
los diferentes componentes del sistema; mientras que en el modelo de
estado se plantean los diferentes estados por los que pasan los elementos
funcionales del sistema.
Tabla 8-Componentes - Vista Despliegue
60
Componente Vista Funcional
Vista Despliegue
Servicios Inicio
Presente
Servicios Seguridad
Presente
Servicios Requisicion
Presente
Servicios Compra
Presente
Servicios Catalogo
Presente

Servicios Aprovacion
Presente
Servicios Reportes Logs
Presente
Data Services
Presente
En la tabla anterior se presentan los elementos funcionales del sistema y su

presencia en los componentes fsicos del sistema, corroborando las relaciones
existentes entre el punto de vista funcional y el punto de vista de despliegue.
En el punto de vista Funcional se analizan los diferentes casos de uso que se
identificaron para la aplicacin que se pretende desarrollar, sin embargo, stos no
pueden mostrar las operaciones y cambios internos que sufren los elementos en
los distintos procesos de la aplicacin. Aunque los casos de uso describen las
actividades que sigue el sistema resultando en un producto final concreto.
En el punto de vista de Informacin se presentan los diagramas de ciclo de vida
que pretenden mostrar los diferentes cambios que sufren los elementos a lo largo
de su vida en la aplicacin y los estmulos que los ejecutan.
En la siguiente tabla se pretende contrastar los elementos funcionales y sus
correspondientes casos de uso identificados, de forma granular, contrastndolos
con los diferentes estados por los que pasan los mismos durante su ciclo de vida
en el sistema.
Tabla 9-Comparacin Funcional-Vista
Vista Funcional
Componentes
Caso de Uso
Vista Informacin
Diagrama de Ciclo de
Vida
61

Crear Requisicin
Requisicin
Administrar
Requisiciones
Aprobar/Rechazar
Requisicin
Consultar Requisicin
Crear Orden de
Compra
Orden de Compra
Administrar Ordenes
de Compra
Pagar Orden de
Compra
Consultar Orden de
Compra
Crear Cotizacin
Cotizacin
Administrar
Cotizaciones
Recibir Cotizacin
Consultar Cotizacin
Crear Usuario
Usuario
Administrar Usuarios
Modificar Usuario
Consultar Usuario
Crear Producto
Producto
Administrar Productos
Consultar Producto
62

Crear Proveedor
Administrar
Proveedor
Proveedores
Actualizar Proveedor
Consultar Proveedor
Crear Historial
Historial
Administrar Historiales
Consultar Historial
Crear Categora
Categora
Administrar Categoras
Modificar Categora
Consultar Categora
4. PlandePruebas
Tabla 10-Prueba 1: Validacin de un usuario
Caso 1
Validar un usuario existente
Identificador de Prueba
PR1 C1
Descripcin
Se intenta validar un usuario que existe en la

base de datos de la aplicacin
Paso
Usuario
El usuario ingresa su login y password y en la

pgina de inicio.
Sistema
El sistema obtiene el login y el password y

verifica la existencia del usuario en el sistema.
63

Resultado Esperado
Dado que el usuario existe en el sistema, el

sistema le permite el ingreso a al pgina
principal de la aplicacin.
Caso 2
Validar un usuario inexistente
PR1 C2
Descripcin
Se intenta validar un usuario que existe en la

base de datos de la aplicacin
Paso
Usuario
El usuario ingresa su login y password y en la

pgina de inicio.
Sistema
El sistema obtiene el login y el password y

verifica la existencia del usuario en el sistema.
Resultado Esperado
Dado que el usuario no existe en el sistema, el

sistema
presenta
la
pgina
de
inicio
nuevamente, con una notificacin de que el

login y el password son invlidos.
Tabla 11-Prueba 2: Cotizar un item
Caso 1
Cotizar un tem 3 veces
PR2 C1
Descripcin
Se intenta realizar 3 cotizaciones a un tem que

se encuentra en el departamento de compras
para ser adquirido.
Paso
64

Usuario
El usuario escoge 3 proveedores para realizar

cotizacin sobre el tem que se est procesando.
Sistema
El sistema adiciona las cotizaciones que se

realizan al tem, y procede a enviarle la
informacin de cotizacin al usuario.
Resultado Esperado
El
sistema
debe
permitir
adicionar
las
cotizaciones al tem y procesarlas.
Caso 2
Cotizar un tem una cuarta vez
PR2 C2
Descripcin
Se intenta realizar una cuarta cotizacin al tem

que se est procesando.
Paso
Usuario
El usuario intenta realizar una cuarta cotizacin

sobre el tem que se est procesando.
Sistema
El sistema debe indicarle al usuario que ya se

han realizado las 3 posibles cotizaciones sobre el
tem y que no se pueden realizar ms.
Resultado Esperado
El sistema debe desplegarle al usuario un

mensaje
indicndole
que
est
intentando
realizar una operacin invlida.
Tabla 12-Prueba 3: Agregar un producto al catlogo
Caso 1
Agregar un producto al catlogo
PR3 C1
Descripcin
Se intenta agregar un producto al catlogo de la

empresa
65

Paso
Usuario
El
usuario
ingresa
en
la
pgina
de
adicionamiento de productos al catlogo e

ingresa los datos necesarios del producto:
categora, nombre y cdigo (autogenerado).
Sistema
El sistema obtiene el nombre del producto y la

categora y procede a crear el producto en el
catlogo. Si la categora no existe, se crea en el
catlogo adicionalmente.
Resultado Esperado
Se adiciona el producto al listado del catlogo y

se puede adicionar al formulario de requisicin
que se est procesando.
66

5. EvaluacindelaArquitectura
5.1. rboldeAtributosdeCalidad
Concurrencia
Can/dadde
accesos
concurrentes
(M,H)Puedehabermnimo
150accesosconcurrentesa
naldemes
Tiempode
funcionamientode
backup
(H,H)Elnododerespaldo
debeentraren
funcionamientoenmenosde
1minuto
AccesoalaBasede
Datos
(H,M)Disponibilidaddel
sistema14/6/315(horariosde
ocina)
Reportes
Gerenciales
(H,M)Sedebengenerarreportes
gerenciales
Disponibilidady
Recuperabilidad
Funcionalidad
Escenariosde
Calidad
Tiempode
Sincronizacin
Desempeoy
Escalabilidad
(H,H)Conocerlassolicitudes
decompraenmenosde2
minutosporeldirectorde
compras
(H,H)Conocerelnmerode
radicacindeunardende
compraalusuarioenmenos
de2segundos
Sincronizacinde
Informacin
(H,M)No/carelcambiode
estadodelassolicitudesde
compra
Auten/cacin
(H,L)Auten/carunusuario
parausodelsistema
Autorizacin
(H,M)Sedebenvericarlos
permisosdecadausuario
Buenacurvade
aprendizaje
(L,M)Unapersonapuede
manejarconfacilidadla
aplicacin
Seguridad
Usabilidad
Ilustracin 15-rbol de Escenarios de Calidad
67

Este rbol nos muestra como se priorizan los atributos de calidad ms

importantes de la arquitectura presentada e indican los intereses de los
stakeholders ms relevantes para el desarrollo de la aplicacin.
Este rbol nos puede indicar donde se presentan mayores riesgos y cules son
los atributos de calidad ms crticos a la hora del desarrollo para asegurar su
correcta implementacin y su seguridad.
5.2. AnlisisdeEscenariodeCalidad
Tabla 13-Anlisis Escenario de Calidad
Anlisis Escenario Seguridad

Scenario
Summary
Business Goals
Quality Attribute
Architectural
Approaches and
Reasoning
Risks
Tradeoffs
68
La aplicacin debe ser segura y debe garantizar que

los usuarios nicamente interacten con las
funcionalidades del sistema a las cuales estn
autorizados.
Brindar un nivel de seguridad alto a los usuarios de la
aplicacin y en especial al gerente de la misma, el cual
es el interesado en conocer el manejo que se le est
dando a las requisiciones.
Seguridad.
Decidieron favorecer seguridad con el manejo de roles
y anotaciones de JEE.
Consiste en una considerable reduccin de eficiencia al
tomar las medidas de seguridad en las pruebas. El
tiempo prcticamente se duplica.
Al darle prioridad a la seguridad disminuye de manera
significativa el desempeo de la aplicacin, el tiempo
de respuesta aumenta considerablemente.

6. ArquitecturaSOA(ServiceOriented
Architecture)
6.1. PortafoliodeServicios
Portafoliode
Servicios
Legacy
Technical
Por\olio
Business
Abstrac/on
Techinical
Business
Historiales
Portal
Funcionarios
Pagos
Electrnicos
Portal
Proveedores
Servidor
Aplicacin
Manejode
Requisiciones
No/caciones
aProveedores
Portal
Inventario
ServidorBase
deDatos
Manejode
Usuarios
Backupde
Informes
LectorCdigos
Inventario
No/caciones
Manejo
Proveedores
Backupde
Inventario
Componente
deSeguridad
Reportes
Gerenciales
Facturacin
Ilustracin 16-Portafolio de Servicios SOA
69

En el diagrama previo se presenta la estructura general del portafolio de

servicios de una arquitectura SOA. Para efectos de la arquitectura candidata
que en esta seccin se presenta, no se va a analizar la seccin Portfolio de la
estructura del portafolio de servicios.
6.2. ModelodeAtributos
Nivel1>AtributosPrincipales
Estadis/cas
ControlOperaciones
No/caciones
Concurrencia
Disponibilidad
Seguridad
Nivel2
Estadis/casControl
ControlNo/caciones
ConcurrenciaControl
DisponibilidadControl
SeguridadControl
Nivel3
DisponibilidadSeguridadConcurrencia
SeguridadControlNo/caciones
Estadis/casControlSeguridad
Nivel4
SeguridadConcurrencia
ControlNo/caciones
DisponibilidadConcurrencia
No/cacionesControl
Estadis/casControl
SeguridadNo/caciones
Estadis/casControl
SeguridadConcurrencia
DisponibilidadConcurrencia
No/cacionesSeguridad
Nivel5
Estadis/casControlConcurrenciaDisponibilidadSeguridad
70
Estadis/casControlDisponibilidadSeguridadNo/caciones
Ilustracin 17-Modelo de Atributos


6.3. ModelodeTaxonomadeServicios
Prioridad1
Prioridad2
Servicios
Conceptuales
Estadis/cas
Control
Operaciones
Informes
Generles
Control
Operaciones
Reportes
Gerenciales
Historiales
Informes
Fsicos
Ilustracin 18-Taxonoma de Estadsticas y Control de Operaciones
Control
Operaciones
Prioridad1
Prioridad2
Servicios
Conceptuales
No/caciones
Alertasde
Operaciones
No/caciones
Historiales
Alertasde
Eventos
Ilustracin 19-Taxonoma de Control de Operaciones y Notificaciones
Prioridad1
Prioridad2
Servicios
Conceptuales
Concurrencia
Controlde
Operaciones
Informesde
Acceso
Controlde
Operaciones
Historiales
Ilustracin 20-Taxonoma de Concurrencia y Control de Operaciones
71

Prioridad1
Prioridad2
Servicios
Conceptuales
Disponibilidad
Controlde
Operaciones
Reportesde
Fallas
Controlde
Operaciones
Nodode
Backup
Historiales
Ilustracin 21-Taxonoma de Disponibilidad y Control de Operaciones
Prioridad1
Prioridad2
Servicios
Conceptuales
Seguridad
Controlde
Operaciones
Historialesde
Seguridad
Componente
deSeguridad
Controlde
Operaciones
Historiales
Ilustracin 22-Taxonoma de Seguridad y Control de Operaciones
72

Prioridad1
Prioridad2
Prioridad3
Servicios
Conceptuales
Accesoalnodo
backup
Concurrencia
Recuperacinante
Fallas
Seguridad
Concurrencia
Disponibilidad
Portalde
Funcionarios
Componentede
Seguridad
Concurrencia
Componentede
Seguridad
Seguridad
Portalde
Funcionarios
Concurrencia
Ilustracin 23-Taxonoma de Disponibilidad, Seguridad y Concurrencia
73

Prioridad1
Prioridad2
Prioridad3
No/caciones
Servicios
Conceptuales
Historialesy
Alertasde
Seguridad
Historialesde
Seguridad
Controlde
Operaciones
Alertasde
Seguridad
No/caciones
Componentede
Seguridad
Seguridad
Historialesy
Alertas
No/caciones
Historiales
Controlde
Operaciones
Alertasde
Operaciones
No/caciones
Ilustracin 24-Taxonoma de Seguridad, Control de Operaciones y Notificaciones
74

Prioridad1
Prioridad2
Prioridad3
Seguridad
Servicios
Conceptuales
Historialese
Informesde
Seguridad
Historialese
Informes
Controlde
Operaciones
Informesde
Seguridad
Seguridad
Reportes
Gerenciales
Estads/cas
Historialesde
Seguridad
Seguridad
Historiales
Controlde
Operaciones
Componentede
Seguridad
Seguridad
Ilustracin 25-Taxonoma de Estadsticas, Control de Operaciones y Seguridad
75

6.4. MatricesdeGranularidad
Tres Meses
Granularidad
Alertas de
Seguridad
Alertas de
Operaciones
Doce Meses
Alertas de
Eventos
Reportes de
Fallas
Historiales de
Seguridad
Informes de
Seguridad
Seis Meses
Informes de
Acceso
Reportes
Gerenciales
Portal de
Funcionarios
Nodo de
Backup
Recuperacin
ante Fallas
Informes
Generales
Componente
de Seguridad
Ilustracin 26-Matriz de Granularidad
76

6.5. BlueprintSOA
Ilustracin 27-Blueprint SOA
77

7. ReferenciasBibliogrficas
Presentaciones disponibles en la pgina del curso Arquitectura de
Software 2008-2
Tutorial de Java Server Faces Cupi2
Documentacin de JBoss AS 4.2
Material Obtenido en clase
Consultas al profesor de Arquitectura de Software Universidad de los
Andes
78

8. Directorio
8.1. GlosariodeTrminos
Tabla 14-Glosario de Trminos
Trmino
Definicin
Autenticacin
Verificacin del login y contrasea de un

usuario para la comprobacin de su posibilidad
de uso de la aplicacin.
Autorizacin
Verificacin de permisos del usuario para la

comprobacin del uso de ciertas
funcionalidades.
Bien
Materiales de uso de oficina.
Concurrencia
Accesos simultneos a una funcionalidad

especfica de la aplicacin.
Cotizacin
Informacin de los precios de los tems

requeridos.
Disponibilidad
La disposicin del sistema en operacin.
Estado de solicitud de
Indican el progreso de la compra de los tems.
compra
Pueden ser: seleccionado proveedor, rden de

compra a proveedor, artculo en almacn,
entregado a funcionario.
Hardware
Mquinas fsicas sobre las que funciona el

sistema.
tem de Compra
Bien registrado en una rden de compra.
Logs
Historiales de operaciones realizadas en la

aplicacin con la respectiva informacin
pertinente.
79

Nodo de Operaciones
Punto de funcionamiento de las operaciones de

una aplicacin.
Nmero de Radicacin
Nmero consecutivo que identificacin la rden

de compra.
rden de Compra
Solicitud de una empresa a un proveedor para

la compra de materiales o insumos.
Protocolo de
Reglas a seguir para la identificacin correcta
Identificacin
del usuario que intenta hacer uso de ciertas

funcionalidades.
Proveedor
Empresa o persona que vende bienes al PYME

segn las requisiciones aprobadas.
Requisicin
Peticin de materiales o insumos requeridos

por una unidad organizacional en una
empresa.
Software
Entidades lgicas que utiliza la aplicacin,

incluyendo a la aplicacin misma.
8.2. Acrnimos
Tabla 15Acrnimos
80
Acrnimo
Definicin
CRUD
Create Read Update Delete
HTTP
Hyper Text Transfer Protocol
JSF
Java Server Faces
LAN
Local Area Network
PYME
Pequea y Mediana Empresa
SAD
System Architecture Document
SIROC
Sistema de Requisiciones y rdenes de Compra

TCP
Transmission Control Protocol
WAN
Wide Area Network
Este documento es una adaptacin de la plantilla de documentacin propuesta por

el
Software
Engineering
(http://www.sei.cmu.edu/architecture/arch_doc.html).
El
Institute
documento
ha
sido
modificado con algunas ideas tomadas de:
Documenting Software Architectures: Views and Beyonds, Clements, Paul.

Adisson-Wesley, 2002.
Software Systems Architectures Working with Stakeholders Using

Viewpoints and Perspectives. Rozanski Nick, Woods Eoin. Adisson-Wesley.
2005.
81

Documento de Sad

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Documento de Sad

Caricato da

Copyright:

Formati disponibili

Universidaddelos

Nombre del Equipo de Trabajo:

Bogot D.C. 2008

Universidad de los Andes

ltima actualizacin: martes, 20 de enero de 2009

Universidad de los Andes

Lista de Tablas ........................................................................................7

Universidad de los Andes

3.2.5. Desempeo y Escalabilidad Tiempo de Sincronizacin...................35

Usabilidad Buena Curva de Aprendizaje ....................................39

ltima actualizacin: martes, 20 de enero de 2009

Universidad de los Andes

4.4.2. Modelo de concurrencia ................................................................54

ltima actualizacin: martes, 20 de enero de 2009

Universidad de los Andes

ILUSTRACIN 1-DIAGRAMA DE CASOS DE USO ............................................................12

ltima actualizacin: martes, 20 de enero de 2009

Universidad de los Andes

ltima actualizacin: martes, 20 de enero de 2009

Universidad de los Andes

Se necesita desarrollar una aplicacin que permita hacer requisiciones por

ltima actualizacin: martes, 20 de enero de 2009

Universidad de los Andes

En este documento, presentamos de una forma exhaustiva la arquitectura del

ltima actualizacin: martes, 20 de enero de 2009

Universidad de los Andes

grado de seguridad al separar los componentes de presentacin, lgica

ltima actualizacin: martes, 20 de enero de 2009

Universidad de los Andes

ltima actualizacin: martes, 20 de enero de 2009

Universidad de los Andes

Ilustracin 1-Diagrama de Casos de Uso

En el previo diagrama se presentan las diferentes funcionalidades que

ltima actualizacin: martes, 20 de enero de 2009

Universidad de los Andes

Cualquier funcionario del sistema puede

expedir una requisicin para materiales o

Ingresar tem de compra al

Cualquier funcionario que requiera un

insumo, el cual no se encuentre en el

El director de rea puede objetar el monto

y el propsito de la compra. El formulario

El director de rea puede aprobar un

formulario de requisicin, el cual se enva

Se solicitan 3 cotizaciones a proveedores

por cada tem en los formularios de

Generar orden de compra

Una vez el proveedor es seleccionado se

El proveedor seleccionado puede hacer

ltima actualizacin: martes, 20 de enero de 2009

Universidad de los Andes

entregas parciales o totales de un bien.

Cerrar orden de compra

Una vez la entrega se han entregado todos

Se consultan estadsticas referentes al

proceso de requisiciones tales como total

Luego de que una compra sea aceptada se

debe informar el evento al director del

Notificar Cambio de estado

Notificar luego de cada evento importante

Debern generarse registros o logs de las

operaciones realizadas en el sistema.