documento de sad

Universidaddelos

AndesSistemadeRequisicionesyrdenesdeCompra(SIROC)DocumentodeArquitecturadelSistema(SAD)Nombre del Equipo de Trabajo:

N/A Nombre de los Integrantes: Diego Avendao

e-mail: [email protected]

Laura Manzur e-mail: [email protected]

Fabin Morales

e-mail: [email protected]

Bogot D.C. 2008

Universidad de los Andes Arquitectura de Software 2008-2

Sistema de Requisiciones y rdenes de Compra (SIROC)

ltima actualizacin: martes, 20 de enero de 2009 2

Versin Modificado Por Fecha Comentarios

1.0 Laura Manzur Diego Avendao Fabin Morales

mircoles, 05 de noviembre de 2008

Creacin del documento de Arquitectura del sistema Perspectivas de calidad y Escenarios de calidad Diagramas


sbado, 08 de noviembre de 2008

Puntos de vista de informacin Escenarios de calidad


jueves, 27 de noviembre de 2008

Arquitectura SOA

2.1 Laura Manzur Diego Avendao

Lunes, 01 de Diciembre de 2008

Blueprint SOA Relaciones entre Puntos de Vista

Universidad de los Andes Arquitectura de Software 2008-2 Sistema de Requisiciones y rdenes de Compra (SIROC)


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



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




1. Contexto1.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. DescripcinGeneraldelSistemaaDesarrollar

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. ObjetivosLos 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. FundamentodelaSolucinEn 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.



1.2.2. AnlisisdeResultadosEsta 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.




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.



T

Tabla 1-Casos de Uso del Sistema

Caso de Uso Descripcin

Iniciar Sesin Cualquier funcionario del sistema puede

ingresar con su login y contrasea a la

aplicacin.

Diligenciar formato de

requisicin

Cualquier funcionario del sistema puede

expedir una requisicin para materiales o

insumos.

Ingresar tem de compra al

catalogo de la empresa

Cualquier funcionario que requiera un

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

requisicin

El director de rea puede objetar el monto

y el propsito de la compra. El formulario

se retorna al funcionario que lo solicit.

Aprobar un formulario de

requisicin

El director de rea puede aprobar un

formulario de requisicin, el cual se enva

al departamento de compras.

Solicitar cotizaciones a

proveedores

Se solicitan 3 cotizaciones a 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




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

Gerenciales

Se consultan estadsticas referentes al

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

compra

Luego de que una compra sea aceptada se

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.

Generacin de Registro

Operaciones

Debern generarse registros o logs de las

operaciones realizadas en el sistema.



2. StakeholdersEsta 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 y

administradores.

Customer

Application software

developers

Infrastructure

software developers

End users

Application system

engineers

Application

hardware engineers

Project manager

Communications

engineers

Chief Engineer/Chief

Scientist

Program

management

System and software

integration and test

engineers

Safety engineers and

certifiers

External

organizations

Operational system

managers

Trainers

Maintainers

Auditors

Security engineers

and certifiers




Ilustracin 2-Organigrama de la Empresa



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

Operaciones

Encargado de las sucursales de la empresa. Administra

los nodos de operaciones.

Desarrolladores Encargado de disear la arquitectura de la aplicacin y

desarrollar sus funcionalidades, atendiendo a las

especificaciones de los stakeholders y sus intereses.

Tabla 3-Stakeholders y Concerns

Stakeholder Concerns

Funcionario 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




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 Ingresar de forma fcil y rpida al sistema.

Conocer solicitudes de compra aceptadas en

menos de dos minutos.

Gerente Ingresar de forma fcil y rpida al sistema.

Tener reportes gerenciales disponibles en todo

momento.

Director de Sistemas 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

Operaciones

Disponibilidad de la aplicacin.

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

Stakeholder Viewpoint

Funcionario Operational Viewpoint



Director de rea Operational Viewpoint, Information Viewpoint

Director de Compras Operational Viewpoint, Functional Viewpoint

Gerente Operational Viewpoint

Director de Sistemas Functional Viewpoint, Deployment Viewpoint,

Concurrency Viewpoint, Information Viewpoint

Director de

Operaciones

Deployment Viewpoint, Information Viewpoint

Desarrolladores Development Viewpoint




3. AtributosdeCalidad3.1. PerspectivasEsta 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. CalidadDeseadaLa 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. AplicabilidadEsta 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.



3.1.1.3. ConcernsSe 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 y herramientas conocidos en

seguridad.

Permitir una correcta identificacin y autenticacin.

Ofrecer mecanismo de auditoras.

Asegurar integridad de la informacin y usar

mecanismos de recuperacin.

3.1.2. Usabilidad

3.1.2.1. CalidadDeseadaPara 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.




3.1.2.2. AplicabilidadEsta 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. ConcernsManejo 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.

3.1.2.4. Actividades 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.



3.1.3. Internacionalidad

3.1.3.1. CalidadDeseadaLa aplicacin no es exclusiva de un lenguaje particular.

Asegura la universalidad en base a uno de los idiomas

utilizados: ingls.

3.1.3.2. AplicabilidadEsta 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. ConcernsFacilitar la interaccin del usuario con la aplicacin sin

discriminacin de idioma o lenguaje. Permitir la universalidad

de la aplicacin.

3.1.3.4. Actividades

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.




3.1.4. Evolucin

3.1.4.1. CalidadDeseadaLa 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. ConcernsFacilitar 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.

3.1.4.4. Actividades Identificar los posibles cambios a realizar en los

componentes de la aplicacin.

Analizar el impacto que los posibles cambios pueden

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

3.1.5.1. CalidadDeseadaLa 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.

3.1.5.2. AplicabilidadEsta perspectiva afecta el punto de vista de despliegue dado

que hay una dependencia tecnolgica del usuario.

3.1.5.3. ConcernsPermitir que todos los usuarios puedan acceder a la

aplicacin desde sus propias mquinas, sin requerir de

instalaciones especiales o tecnologas especficas.

3.1.5.4. Actividades 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.




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

3.1.6.1. CalidadDeseadaSe 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.

3.1.6.2. AplicabilidadLos 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. ConcernsTiempo que el sistema se mantiene operacional, habilidad de

recuperacin ente fallas e inconvenientes.

3.1.6.4. Actividades Implementar pruebas unitarias, de aceptacin, de

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

3.1.7.1. CalidadDeseadaLa 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.

3.1.7.2. AplicabilidadEsta 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. ConcernsTener tiempos de respuesta rpidos independientes de la

ubicacin del usuario en relacin con la ubicacin fsica de la

aplicacin.

3.1.7.4. Actividades




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

3.1.8.1. CalidadDeseadaLa 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



que se escojan y los medios de comunicacin de los

diferentes mdulos afectan el desempeo del sistema.

3.1.8.3. ConcernsTiempos de respuesta, soporte para ciento cincuenta (150) o

ms accesos concurrentes al sistema, crecimiento de la

compaa.

3.1.8.4. Actividades 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




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

3.2.1.1. DescripcinDurante 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. FuenteTodos los usuarios

3.2.1.3. Estimulo Realizar una requisicin

Consultas de rdenes de compra

Aprobar/Objetar una requisicin

Consultar reportes gerenciales



Realizar cotizaciones

Consultar logs

3.2.1.4. ArtefactoMdulo SIROC

3.2.1.5. AmbienteCondiciones normales

3.2.1.6. RespuestaAccesos a la aplicacin y ejecucin correcta de la misma

3.2.1.7. MedidadelaRespuestaNmero de accesos concurrentes

3.2.2. DisponibilidadyRecuperabilidadTiempodefuncionamientodelbackup

3.2.2.1. DescripcinEn 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. FuenteMdulo SIROC y Director de Operaciones




3.2.2.3. Estimulo Poner en funcionamiento la aplicacin nuevamente


3.2.2.5. AmbienteNodo central cado

3.2.2.6. RespuestaFuncionamiento correcto del sistema bajo el segundo nodo

3.2.2.7. MedidadelaRespuestaTiempo de funcionamiento del nodo de backup menor a un

(1) minuto

3.2.3. DisponibilidadyRecuperabilidadAccesoalaBasedeDatos

3.2.3.1. DescripcinLa 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. FuenteMdulo SIROC



3.2.3.3. Estimulo Acceder a la base de datos

Persistir cambios

Realizacin de consultas a la base de datos


Nivel de persistencia

3.2.3.5. AmbienteCondiciones normales

3.2.3.6. RespuestaFuncionamiento normal de la base de datos, consultas y

persistencia efectuada satisfactoriamente durante el tiempo

de uso.

3.2.3.7. MedidadelaRespuestaTiempo de funcionamiento de la base de datos 14/6/315

3.2.4. FuncionalidadReportesGerenciales

3.2.4.1. DescripcinSe 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




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.


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. ArtefactoMdulo SIROC, Base de datos

3.2.4.5. AmbienteFuncionamiento normal de la aplicacin

3.2.4.6. RespuestaReportes gerenciales actualizados luego de efectuar alguna

operacin y documentacin de esta ltima (funcionario que

efectu la operacin, fecha, descripcin de la operacin etc.)

3.2.4.7. MedidadelaRespuestaToda operacin debe estar documentada en los registros y

generar la actualizacin de los reportes luego de ser

efectuada.



3.2.5. DesempeoyEscalabilidadTiempodeSincronizacin

3.2.5.1. DescripcinAl 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. FuenteFuncionario

3.2.5.3. Estimulo Diligenciamiento de un formulario de requisicin


3.2.5.5. AmbienteCondiciones Normales

3.2.5.6. RespuestaRecepcin del formulario de requisicin para aprobacin por

el director de rea

3.2.5.7. MedidadelaRespuestaTiempo de recepcin del formulario de requisicin por el

director de rea correspondiente menor o igual a dos (2)

minutos

3.2.6. DesempeoyEscalabilidadTiempodeSincronizacin

3.2.6.1. Descripcin




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




3.2.6.6. RespuestaObtencin del nmero de radicacin del formulario de

requisicin diligenciado.

3.2.6.7. MedidadelaRespuestaTiempo de obtencin del nmero de radicacin menor a dos

(2) segundos.

3.2.7. DesempeoyEscalabilidadSincronizacindeInformacin

3.2.7.1. DescripcinLuego 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



estado que puede tener una requisicin: pendiente,

aprobada, cotizacin, proveedor, inventario.





3.2.7.6. RespuestaNotificacin de los cambios de estado de los formularios de

requisicin diligenciados.

3.2.7.7. MedidadelaRespuestaSincronizacin de la informacin correspondiente a los

cambios de estado de los formularios de requisicin.

3.2.8. SeguridadAutenticacin

3.2.8.1. DescripcinCuando 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




Usuario

3.2.8.3. Estimulo Es necesario administrar y almacenar de una

manera correcta las cuentas de los usuarios

3.2.8.4. ArtefactoModulo Siroc, base de datos

3.2.8.5. AmbienteUna 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. RespuestaCada persona ingresara al sistema despus de la

comprobacin en la base de datos.

3.2.8.7. MedidadelaRespuestaSi 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. DescripcinCuando 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



Usuario

3.2.9.3. Estimulo Ser necesario crear administrar permisos para la

aplicacin. Estos se harn mediante los roles

3.2.9.4. ArtefactoBase de datos, Modulo SIROC

3.2.9.5. AmbienteLuego 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. RespuestaCada persona tendr permisos de acuerdo a su rol

3.2.9.7. MedidadelaRespuestaEl usuario solo podr interactuar con la aplicacin, de

acuerdo a los privilegios que tenga

3.2.10. UsabilidadBuenaCurvadeAprendizaje

3.2.10.1. DescripcinTodos los usuarios que interacten con la aplicacin,

debern aprender a manejarla de una manera rpida

3.2.10.2. FuenteUsuario

3.2.10.3. Estimulo




Es indispensable que los usuarios se adapten rpidamente a la aplicacin

3.2.10.4. ArtefactoCapa web

3.2.10.5. AmbienteLa 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. RespuestaCorrecta utilizacin de todas las funciones bsicas de la

aplicacin.

3.2.10.7. MedidadelaRespuestaEl usuario deber aprender las funciones bsicas de la

aplicacin en un tiempo no menor a 2 horas



4. PuntosdeVistaEsta 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. PuntodeVistadeDespliegue4.1.1. DescripcinEl 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.




4.1.2. ModelosdePlataformadeEjecucinydeRed

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.



4.1.3. ModelosdeDependenciaTecnolgicaTabla 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. PuntodeVistaFuncional4.2.1. DescripcinEl 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.




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



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.




4.2.3. ModelodeProcesosdeNegocio

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.

Funcionario

Director rea

Director Compras

Director Sistemas

Gerente General



4.3. PuntodeVistadeInformacin4.3.1. DescripcinDescribe 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. ModelosdeEstructurasEstticasdeDatos

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.




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

OrdenCompra

Indica que las rdenes de compra

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 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 los usuarios tienen

asociados historiales los cuales

tienen registros de las operaciones

realizadas por ese usuario

4.3.3. ModelosdeFlujodeInformacinLos 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.




4.3.3.1. ModelodeFlujodeInformacindeunaRequisicin

Ilustracin 8-Flujo Informacin Requisicin



4.3.3.2. ModelodeFlujodeInformacindeunardendeCompra

Ilustracin 9-Flujo Informacin rden de Compra

4.3.4. ModelodePropiedaddelosDatosEl 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.

Tabla 7-Permisos de los Usuarios y Elementos sobre la Informacin

Req

uisi

cin

tem

Pro

duct

o

Cot

izac

in

Ord

en

Com

pra

Rep

orte

s G

eren

cial

es

His

tori

ale

s

Funcionario CR CR Director Compras

CR CR CRUD

CRUD




Director Sistemas

CR CR R

Director Operaciones

CR CR

Gerente CR CR R SIROC U CRU CU CU Catlogo CRU Requisicin CRU

D

4.3.5. ModelosdeCiclodeVidadeInformacin

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

Ilustracin 10-Ciclo de Vida Requisicin



4.3.5.2. ModelodeCiclodeVidadeunardendeCompra

Ilustracin 11-Ciclo de Vida rden de Compra

4.3.5.3. ModelodeCiclodeVidadeunaCotizacin

Ilustracin 12-Ciclo de Vida Cotizacin

4.3.5.4. ModelodeCiclodeVidadeunUsuario

Ilustracin 13-Ciclo de Vida Usuario




4.4. PuntodeVistadeConcurrencia4.4.1. DescripcinDescribe 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



4.4.3. Modelosdeestado

4.4.3.1. ServiciosInicio

4.4.3.2. ServiciosRequisicin




4.4.3.3. Serviciosaprobacin

4.4.3.4. Servicioscatlogo



4.4.3.5. Servicioscompra

4.4.3.6. Serviciosseguridad




4.4.3.7. Dataservices

3.1. RelacionesentrelosPuntosdeVista



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




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

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 Vista Informacin

Componentes Caso de Uso Diagrama de Ciclo de

Vida




Crear Requisicin

Aprobar/Rechazar

Requisicin Requisicin

Administrar

Requisiciones

Consultar Requisicin

Crear Orden de

Compra

Pagar Orden de

Compra Orden de Compra

Administrar Ordenes

de Compra

Consultar Orden de

Compra

Crear Cotizacin

Recibir Cotizacin Cotizacin Administrar

Cotizaciones

Consultar Cotizacin

Crear Usuario

Modificar Usuario Usuario Administrar Usuarios

Consultar Usuario

Crear Producto

Producto Administrar Productos

Consultar Producto



Crear Proveedor

Actualizar Proveedor Proveedor Administrar

Proveedores

Consultar Proveedor

Crear Historial

Historial Administrar Historiales

Consultar Historial

Crear Categora

Modificar Categora Categora Administrar Categoras

Consultar Categora

4. PlandePruebasTabla 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 1

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 existe en el sistema, el

sistema le permite el ingreso a al pgina

principal de la aplicacin.

Caso 2 Validar un usuario inexistente


Descripcin Se intenta validar un usuario que existe en la

base de datos de la aplicacin

Paso 1

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


Descripcin Se intenta realizar 3 cotizaciones a un tem que

se encuentra en el departamento de compras

para ser adquirido.

Paso 1



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 3

cotizaciones al tem y procesarlas.

Caso 2 Cotizar un tem una cuarta vez


Descripcin Se intenta realizar una cuarta cotizacin al tem

que se est procesando.

Paso 1

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


Descripcin Se intenta agregar un producto al catlogo de la

empresa




Paso 1

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.



5. EvaluacindelaArquitectura5.1. rboldeAtributosdeCalidad

Ilustracin 15-rbol de Escenarios de Calidad

EscenariosdeCalidad

ConcurrenciaCan/daddeaccesos

concurrentes

(M,H)Puedehabermnimo150accesosconcurrentesa

finaldemes

DisponibilidadyRecuperabilidad

Tiempodefuncionamientode

backup

(H,H)Elnododerespaldodebeentraren

funcionamientoenmenosde1minuto

AccesoalaBasedeDatos

(H,M)Disponibilidaddelsistema14/6/315(horariosde

oficina)

Funcionalidad ReportesGerenciales(H,M)Sedebengenerarreportes

gerenciales

DesempeoyEscalabilidad

TiempodeSincronizacin

(H,H)Conocerlassolicitudesdecompraenmenosde2minutosporeldirectorde

compras

(H,H)Conocerelnmeroderadicacindeunardendecompraalusuarioenmenos

de2segundos

SincronizacindeInformacin

(H,M)No/ficarelcambiodeestadodelassolicitudesde

compra

Seguridad

Auten/cacin (H,L)Auten/carunusuarioparausodelsistema

Autorizacin (H,M)Sedebenverificarlospermisosdecadausuario

Usabilidad Buenacurvadeaprendizaje(L,M)Unapersonapuedemanejarconfacilidadla

aplicacin




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. AnlisisdeEscenariodeCalidadTabla 13-Anlisis Escenario de Calidad Anlisis Escenario Seguridad Scenario Summary

La aplicacin debe ser segura y debe garantizar que los usuarios nicamente interacten con las funcionalidades del sistema a las cuales estn autorizados.

Business Goals 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.

Quality Attribute Seguridad. Architectural Approaches and Reasoning

Decidieron favorecer seguridad con el manejo de roles y anotaciones de JEE.

Risks Consiste en una considerable reduccin de eficiencia al tomar las medidas de seguridad en las pruebas. El tiempo prcticamente se duplica.

Tradeoffs Al darle prioridad a la seguridad disminuye de manera significativa el desempeo de la aplicacin, el tiempo de respuesta aumenta considerablemente.



6. ArquitecturaSOA(ServiceOrientedArchitecture)

6.1. PortafoliodeServicios

Ilustracin 16-Portafolio de Servicios SOA

PortafoliodeServicios

Legacy

Technical

Historiales

ServidorAplicacin

ServidorBasedeDatos

No/ficaciones

ComponentedeSeguridad

Business

PortalFuncionarios

ManejodeRequisiciones

ManejodeUsuarios

ManejoProveedores

ReportesGerenciales

Facturacin

Por\olio Abstrac/on

Techinical

PagosElectrnicos

No/ficacionesaProveedores

BackupdeInformes

BackupdeInventario

Business

PortalProveedores

PortalInventario

LectorCdigosInventario




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

Ilustracin 17-Modelo de Atributos

Nivel5

Estadis/casControlConcurrenciaDisponibilidadSeguridad Estadis/casControlDisponibilidadSeguridadNo/ficaciones

Nivel4

SeguridadConcurrenciaControlNo/ficaciones

DisponibilidadConcurrenciaNo/ficacionesControl

Estadis/casControlSeguridadNo/ficaciones

Estadis/casControlSeguridadConcurrencia

DisponibilidadConcurrenciaNo/ficacionesSeguridad

Nivel3

DisponibilidadSeguridadConcurrencia SeguridadControlNo/ficaciones Estadis/casControlSeguridad

Nivel2

Estadis/casControl ControlNo/ficaciones ConcurrenciaControl DisponibilidadControl SeguridadControl

Nivel1>AtributosPrincipales

Estadis/cas ControlOperaciones No/ficaciones Concurrencia Disponibilidad Seguridad



6.3. ModelodeTaxonomadeServicios

Ilustracin 18-Taxonoma de Estadsticas y Control de Operaciones

Ilustracin 19-Taxonoma de Control de Operaciones y Notificaciones

Ilustracin 20-Taxonoma de Concurrencia y Control de Operaciones

ServiciosConceptuales

Prioridad2

Prioridad1 Estadis/cas

ControlOperaciones

InformesGenerles

ReportesGerenciales

ControlOperaciones

Historiales InformesFsicos


Prioridad2

Prioridad1 ControlOperaciones

No/ficaciones

AlertasdeOperaciones Historiales

No/ficaciones

AlertasdeEventos


Prioridad2

Prioridad1 Concurrencia

ControldeOperaciones

InformesdeAcceso


Historiales




Ilustracin 21-Taxonoma de Disponibilidad y Control de Operaciones

Ilustracin 22-Taxonoma de Seguridad y Control de Operaciones


Prioridad2

Prioridad1 Disponibilidad


ReportesdeFallas

NododeBackup


Historiales


Prioridad2

Prioridad1 Seguridad


HistorialesdeSeguridad



Historiales



Ilustracin 23-Taxonoma de Disponibilidad, Seguridad y Concurrencia

ServiciosConceptualesPrioridad3Prioridad2Prioridad1

Disponibilidad

Seguridad

Concurrencia

Accesoalnodobackup

RecuperacinanteFallas

Concurrencia PortaldeFuncionarios

Seguridad

Concurrencia



Concurrencia

PortaldeFuncionarios




Ilustracin 24-Taxonoma de Seguridad, Control de Operaciones y Notificaciones


Seguridad


No/ficaciones

HistorialesyAlertasdeSeguridad


No/ficaciones

AlertasdeSeguridad



No/ficaciones

HistorialesyAlertas

Historiales

No/ficaciones

AlertasdeOperaciones



Ilustracin 25-Taxonoma de Estadsticas, Control de Operaciones y Seguridad


Estads/cas


Seguridad

HistorialeseInformesdeSeguridad

HistorialeseInformes

Seguridad

InformesdeSeguridad

ReportesGerenciales


Seguridad


Historiales

Seguridad





6.4. MatricesdeGranularidad

Tres Meses Seis Meses Doce Meses

+

G

ran

ula

rida

d

-

Ilustracin 26-Matriz de Granularidad

Informes Generales

Reportes Gerenciales

Alertas de Operaciones

Alertas de Eventos

Informes de Acceso

Reportes de Fallas

Nodo de Backup

Historiales de Seguridad

Recuperacin ante Fallas

Portal de Funcionarios

Componente de Seguridad

Alertas de Seguridad

Informes de Seguridad



6.5. BlueprintSOA

Ilustracin 27-Blueprint SOA




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



8. Directorio8.1. GlosariodeTrminosTabla 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

compra

Indican el progreso de la compra de los tems.

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.




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

Identificacin

Reglas a seguir para la identificacin correcta

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. AcrnimosTabla 15Acrnimos

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

Universidad de los Andes Arquitectura de Software 2008-2 Sistema

Documents

documento de sad