Arquitectura de un modulo I/O para objetos...

Arquitectura de un modulo I/O para objetos 3D Pontificia Universidad Javeriana

ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE

2011/11/26

1.4

Andres Harker Gutierrez

Director: Ing. Cesar Julio Bustacara Medina

Ingeniería de Sistemas PUJ 1

SRS: Arquitectura de un modulo I/O para objetos 3D

Contenido

CONTENIDO........................................................................................................................................ 1

LISTA DE TABLAS ............................................................................................................................. 2

LISTA DE ILUSTRACIONES ............................................................................................................. 3

1 INTRODUCCIÓN ................................................................................................................................... 4

1.1. PROPÓSITO ............................................................................................................................... 4 1.2. ALCANCE .................................................................................................................................. 4 1.3. APRECIACIÓN GLOBAL .................................................................................................................. 5

2 DESCRIPCIÓN GLOBAL ......................................................................................................................... 6

2.1 PERSPECTIVA DEL PRODUCTO ................................................................................................................ 6 2.1.1 Interfaces con el sistema ........................................................................................................ 6 2.1.2 Interfaces con el usuario ......................................................................................................... 7 2.1.3 Interfaces con el Hardware ..................................................................................................... 7 2.1.4 Interfaces con el Software ...................................................................................................... 8 2.1.5 Interfaces de Comunicación .................................................................................................... 8 2.1.6 Restricciones de Memoria ...................................................................................................... 8 2.1.7 Operaciones ........................................................................................................................... 9 2.1.8 Requerimientos de Adaptación del Sitio .................................................................................. 9

2.2 FUNCIONES DEL PRODUCTO ............................................................................................................ 9 2.3 CARACTERÍSTICAS DEL USUARIO .................................................................................................... 9 2.4 RESTRICCIONES ........................................................................................................................... 10 2.5 MODELO DEL DOMINIO ................................................................................................................ 11 2.6 SUPOSICIONES Y DEPENDENCIAS .................................................................................................. 11 2.7 DISTRIBUCIÓN DE REQUERIMIENTOS ............................................................................................. 11

3 REQUERIMIENTOS ESPECÍFICOS ............................................................................................ 12

3.1 INTERFACES CON EL USUARIO .............................................................................................................. 12 3.2 INTERFACES CON EL HARDWARE........................................................................................................... 12 3.3 RESTRICCIONES DE DISEÑO.......................................................................................................... 13 3.4 REQUERIMIENTOS DE LA BASE DE DATOS ...................................................................................... 13

4 ANEXOS .......................................................................................................................................... 14



Lista de Tablas

Tabla 1 ..................................................................................................................................... 7 Tabla 2 ....................................................................................................................................10 Tabla 3 ....................................................................................................................................10 Tabla 4 ....................................................................................................................................12



Lista de Ilustraciones

Figura Numero 1 ....................................................................................................................... 9 Figura Numero 2 ......................................................................................................................11



1 Introducción

1.1. Propósito

En este documento se dará una formalización de las características y requerimientos

tanto funcionales como no funcionales del modulo de I/O para VITRAL. Haciendo un

especial énfasis en requerimientos no funcionales, características especiales y

restricciones del modulo.

Este documento también dará una visión importante acerca del porque cada una de estas

características que se tendrán en cuenta son importantes no solo para el modulo de I/O

de VITRAL sino en general para un repositorio de objetos 3D.

Este documento, sus anexos y futura evolución serán el insumo principal para el diseño

del repositorio. Tanto a nivel arquitectónico como a nivel detallado, es por esta razón

que tiene como un anexo fundamental un documento de comparación de algunas de las

arquitecturas de software propuestas hasta el momento para repositorios de objetos 3D.

1.2. Alcance

Descripción del producto El producto consiste en un modulo que se encargue de manera ordenada y correctamente

indexada de la manipulación de la información correspondiente a objetos 3D. Para que estos objetos puedan ser utilizados en aplicaciones graficas, de tal forma que la persistencia,

recuperación y la aplicación de filtros necesarios para las aplicaciones graficas sea transparente a

los desarrolladores.

Principalmente lo usarían desarrolladores y diseñadores de aplicaciones graficas aunque el ideal

es enfocarlo a que sea un gran repositorio en el cual tanto ingenieros de desarrollo, diseñadores

gráficos e industriales, y casi cualquier persona que pueda necesitar de objetos 3D en su área de conocimiento. Pueda aportar a este repositorio de objetos 3D y valerse de el.

El objetivo es poder apoyar a cualquier rama que necesite valerse de objetos 3D y el correcto

almacenamiento y recuperación de los mismos. Principalmente tendrá funcionalidades de guardado e indexado de objetos 3D, recuperación y filtros sobre objetos 3D y finalmente

actualizaciones sobre objetos 3D existentes. No tendrá interfaces con consumidores humanos

aparte de los ambientes de pruebas y archivos de configuración.



1.3. Apreciación Global

Básicamente obviando esta sección introductoria el documento consta de 2 partes fundamentales y a su vez cuenta dentro de estas partes. Tres puntos fundamentales en los cuales estará centrado.

Hablando de las partes principales del documento, son la descripción global y los requerimientos específicos.

Descripción global

Los principales interesados en este fragmento del documento son stakeholders externos al producto quienes no serán clientes directos del modulo. Entendiendo como clientes directos del modulo a desarrolladores que utilicen VITRAL como herramienta de desarrollo o equipos que necesiten directamente entender los modelos que compondrán el modulo. Servirá para dar una orientación de las características fundamentales del modulo, como interactuara con otros sistemas y con usuarios, etc. Y finalmente se utilizara durante el proceso de diseño e implementación como una guía visionaria del producto final.

Requerimientos específicos

Los principales interesados son los clientes directos del modulo, tales como desarrolladores de VITRAL y desarrolladores con VITRAL. Orientara tanto el diseño como el desarrollo pero no solo como una visión sino como una especificación.

Este fragmento cuenta con dos puntos fundamentales que son los requerimientos funcionales y los atributos de calidad, debido a que será un gran insumo para el núcleo fundamental que es la arquitectura del modulo.



2 Descripción Global

Principalmente el producto se ve afectado por el grado de exactitud que se desee en las

comparaciones de objetos 3D que sean requeridas y los atributos de calidad que primen.

Y en cuanto a los requerimientos la principal influencia que tienen son las necesidades y

filosofía de VITRAL y las necesidades específicas que pueda tener un interesado en el

repositorio 3D. Básicamente el entorno del desarrollo de aplicaciones graficas es el que

influye tanto en el producto como en sus requerimientos.

2.1 Perspectiva del Producto

Siendo este producto un componente especifico del framewok VITRAL. Es importante

resaltar que una correcta administración de la persistencia de los objetos 3D llevara a

facilitar la colaboración en el desarrollo de aplicaciones graficas y en que personas de

otras ramas de conocimiento como diseñadores aporten a este repositorio o se vean

beneficiados por el mismo.

Funcionalidades nuevas aportadas a VITRAL.

Aunque ya existen funcionalidades de guardado y recuperación de archivos que

representen objetos 3D directamente del sistema de archivos una correcta

manipulación en sistemas especialización de almacenamiento, puede aumentar su

desempeño y disminuir su dependencia del sistema de archivos y del sistema

operativo.

Brindar una capa de atracción en cuanto a los filtros de recuperación de objetos

3D, esto con el objetivo de desligar la lógica de aplicaciones graficas de su lógica

de almacenamiento y recuperación.

2.1.1 Interfaces con el sistema En este caso existen básicamente 3 sistemas externos con los que interactúa el sistema.

Framework VITRAL: Básicamente se prestara un servicio de caja negra para la

persistencia en el cual dados ciertos parámetros, estandarizados por un lenguaje específico que se definirá durante la etapa de implementación como un protocolo de

comunicación, Se retornara uno o varios objetos 3D que puedan manipular las capas de

aplicación como objeto en memoria.

Sistema de archivos: Bien sea directa o indirectamente será necesario interactuar con el

sistema de archivos del sistema operativo. Debido a la filosofía inicial de VITRAL, se comunicara con el sistema de archivos y el sistema operativo por medio de la maquina

virtual de java. Y se accederá directamente para recuperar la estructura completa de cada

objeto 3D. Dependiendo de un análisis posterior es posible que esta interacción se dé por medio de un DBMS

Sistema manejador de base de datos: Este sistema manejara el indexa miento y servirá

como motor de búsqueda y filtro, es importante resaltar que se especifica la interacción



con la base de datos que aunque es parte del sistema juega un papel muy importante porque tiene que poder ser genérico en cuanto al motor de base de datos.

2.1.2 Interfaces con el usuario

Tabla 1

2.1.3 Interfaces con el Hardware

Es necesario que el hardware apoye una distribución del componente en varias maquinas físicas, virtuales o mezcladas. En cuanto a la infraestructura física puede ser variable siempre y cuando me permita esa distribución del modelo y las maquinas se puedan comunicar entre sí mediante protocolos estándares del modelo de TCP/IP, tales como TCP o HTTP.

El objetivo principal de soportar estos protocolos TCP/IP es poder tanto usar el componente en una intranet o poderlo escalar hacia una red de área amplia o por qué no, internet.

Interfaces genericas para el programador• Debido a que es un componente parte de VITRAL, se dejaran interfaces como fachadas y protocolos definidos para el consumo de las funcionalidades del modulo.

Interface de carga de objetos 3D

• Si bien no se dejaran interfaces propias de interaccion con usuarios humanos, se tendran interfaces de software dispuestas a ser consumidas directamente por la interfaz grafica de usuario y asi poder brindar medios de carga de objetos 3D. En el formato que se especifique para su guardado.

Interface de descarga de objetos 3D

• Al igual que la interface para carga de objetos 3D, la interface de descarga sera una interface de software dispuesta para ser conectada directamente con interfaz grafica de usuario u otras aplicaciones.

TCP como protocolo para la comunicacion

• Esto en el caso distribuido, en casos en los que se utilicen en la misma maquina se utilizaran referencias a objetos, esto de forma transparente al consumidor.

GUI de pruebas del modulo

• Esta interfaz sera provista como metodo de prueba de las funcionalidades del modulo

Interfaz web para difusion de las funcionalidades

• Esta interfaz servira tanto de prueba a las funcionalidades del modulo como para generar un interes en los productores de modelos 3D a enriquecer el repositorio con modelos y con ideas de mejora.



Independientemente del hardware y los protocolos que se utilicen para consumir las funcionalidades del modulo, si es indispensable una comunicación rápida y confiable entre las maquinas que posean el modulo y con la base de datos, por eso se sugiere cable UTP o si las maquinas receptoras son lo suficientemente robustas para aprovecharla, fibra óptica.

Sera de vital importancia la definición y pruebas sobre hardware especializado en almacenamiento y acceso a disco y hardware no especializado, sin atar el modelo a ninguno de los dos esta interfaz dará una luz de su relevancia en el modelo.

2.1.4 Interfaces con el Software

Debido a la naturaleza y filosofía del modelo se especificaran interfaces con el software

que parecerán un poco contradictorias como mencionar varios motores de base de datos

o distintos sistemas operativos. Como un requisito sobre el producto es probarlo en al

menos estos sistemas operativos y motores de bases de datos.

Para el detalle de las interfaces de software que se utilizaran en el proyecto, por favor

revise el documento anexo InterfacesConElSoftware_2011_8_19.xslx.

2.1.5 Interfaces de Comunicación

Se utilizara principalmente protocolos de comunicación sobre TCP/IP. De manera específica se planea manejar puertos TCP para el manejo de la comunicación entre las maquinas donde se distribuya el modulo de I/O. Y para un futuro se dejara el modelo en código para que pueda consumirse por medio de HTTP, de esta forma pueden apoyarse en el por el protocolo estándar de internet, lo cual facilita para que muchas más personas lo puedan aprovechar. Para evitar conflictos específicos, cualquier puerto TCP que se utilice podrá ser configurado en los archivos de propiedades del modulo.

2.1.6 Restricciones de Memoria

Precisamente es necesario analizar en el modelo y en lo posible minimizar la cantidad de memoria utilizada, pero se tienen casos especiales y extremos. En un futuro el modulo debe poderse consumir desde dispositivos móviles de entre 256 y 526 MB de Memoria principal. Por esta y por razones de optimización del modelo es necesario llevar el consumo de memoria principal del modulo a lo mínimo posible. Si bien es cierto que un dispositivo de estos no realizaría el procesamiento sino que actuaria en modo cliente, los objetos respuesta si debe cargarlos en memoria.



2.1.7 Operaciones

Como operaciones especiales el modulo debe contar con.

Figura Numero 1

2.1.8 Requerimientos de Adaptación del Sitio

El modulo debe adaptarse a la arquitectura del framework completo de VITRAL, en caso de necesitar cambios el framework se deben realizar y dejar los protocolos dispuestos para asimilar dichos cambios.

2.2 Funciones del Producto

Para detalle de las funcionalidades del producto y a quien prestan sus servicios, por favor revisar el modelo de casos de uso en los anexos.

Modelo de casos de uso EA_2011_11_26.rtf

2.3 Características del Usuario

Filtrar objetos 3D por medio de descriptores, lo cual

dependiendo del diseño de datos, podria implicar distintos indices y formas de realizar los

filtros.

Insertar Objetos 3D en el repositorio, lo cual implica el

calculo de descriptores especiales e informacion extra para su fiutura recuperacion

rapida.

Eliminacion de objetos 3D, lo cual implica quitar indices e

informacion de varios sistemas de indexacion probablemente,

dependiendo del diseño arquitectonico

Proveer servicios mediante protocolos especiales para la integracion con VITRAL, dicha integracion siendo lo menos

traumatica posible tanto para el modulo como para VITRAL

El modulo debe asegurar transaccionalidad a nivel de

objetos 3D

Anexos%20del%20SRS/Modelo%20de%20casos%20de%20uso%20EA_2011_11_26.rtf



Tabla 2

2.4 Restricciones

Tabla 3

Características del Usuario USUARIO_CONFIGURADOR VITRAL

Nivel de Seguridad o de

Privilegios Debe tener acceso a la maquina

fisica donde se encuentre el modulo

de I/O

Despues de autenticarse ante el

modulo, tiene privilegios para todos

los casos de uso excepto la

configuracion

Roles

El usuario configurador tiene un rol

especifico y es el de dejar

configurado el ambiente del

repositorio desde las propiedades

del modulo para que tome de

manera exitosa el motor de base de

datos y su ubicación

Tiene el rol del cliente del modulo,

quien consume sus funcionalidades

(el desarrollador o equipo de

desarrollo de aplicaciones graficas)

Nivel de Estudios o

Experiencia Técnica Nivel de experticia en computacion

alto (entendiendo como alto, una

persona con conocimientos de bases

de datos, conexiones a las mismas y

manejo de puertos TCP basico)

Nivel de experticia en computacion

alto (entendiendo como alto, un

desarrollador para aplicaciones

graficas, diseñador de las mismas o

desde ahí hacia arriba en el nivel de

abstraccion

Frecuencia de Uso

Muy baja, este usuario solo utilizaria

el modulo antes de colocar a

funcionar el contenedor completo.

Muy alta, es el cliente real del

funcionamiento del modulo

El modulo debe ser implementado en lenguaje Java

El modulo no debe estar atado a un motor especifico de base de datos

El modulo debe poder ser ejecutado tanto en ambientes linux como en ambientes windows

El modulo debe ser transaccional a nivel de objeto 3D

El modulo debe tener protocolos de integracion claros con VITRAL

El modulo debe poder ser cosumible desde dispositivos movible que posean JVM

El modulo no tendra pruebas con desarrollo de aplicaciones graficas en esta su primera etapa



2.5 Modelo del Dominio

Para detalle del modelo de dominio que maneja el producto, los conceptos que este maneja y como se relacionan revise el anexo:

Modelo de dominio EA_2011_11_26.rtf

2.6 Suposiciones y Dependencias

Suposiciones Generales:

Figura Numero 2

2.7 Distribución de Requerimientos

No aplica aun porque no se ha definido un modelo de arquitectura de software ni los subsistemas que se tendrán.

Se cuenta con una maquina virtual de java para la

ejecucion.

Se cuenta con un espacio suficiente de

almacenamiento en base de datos como para tener

bancos con imagenes de hasta 4GB

El modulo se podra ejecutar en pc's en los cuales se

tenga acceso a todas las funcionalidades del JDK

estandar

Cumplimiento de los requisitos de hardware

planteados anteriormente

Pontificia universidad javeriana como proveedor del software necesario, ya

mencionado anteriormente

Anexos%20del%20SRS/Modelo%20de%20dominio%20EA_2011_11_26.rtf



3 Requerimientos Específicos

Para información y detalle de cada uno de los requerimientos funcionales y no funcionales de la

aplicación junto con sus respectivos atributos de calidad, revisar el documento anexo.

Modelo de requerimientos EA_2011_11_26.rft

3.1 Interfaces con el Usuario

Tabla 4

3.2 Interfaces con el Hardware

Es necesario que el hardware apoye una distribución del componente en varias maquinas físicas, virtuales o mezcladas. En cuanto a la infraestructura física puede ser variable siempre y cuando me permita esa distribución del modelo y las maquinas se puedan comunicar entre sí mediante protocolos estándares del modelo de TCP/IP, tales como TCP o HTTP.

El objetivo principal de soportar estos protocolos TCP/IP es poder tanto usar el componente en una intranet o poderlo escalar hacia una red de área amplia o por qué no, internet.

Independientemente del hardware y los protocolos que se utilicen para consumir las funcionalidades del modulo, si es indispensable una comunicación rápida y confiable entre las maquinas que posean el modulo y con la base de datos, por eso se sugiere cable UTP o si las maquinas receptoras son lo suficientemente robustas para aprovecharla, fibra óptica.

GUI de pruebas

• interfaz provicional para probar las interfaces expuestas al programador.

Interfaz web de prueba y despliegue

•Con el objetivo de publicar un resultado que sea amigable para la alimentacion del repositorio y para compartir recursos 3D

Pantalla

Teclado

Interface de programador

Anexos%20del%20SRS/Modelo%20de%20requerimientos%20EA_2011_11_26.rtf



Sera de vital importancia la definición y pruebas sobre hardware especializado en almacenamiento y acceso a disco y hardware no especializado, sin atar el modelo a ninguno de los dos esta interfaz dará una luz de su relevancia en el modelo.

3.3 Restricciones De Diseño

Esta sección no aplica aun dado que este documento será insumo para el SAD que especificara dicha arquitectura base

3.4 Requerimientos de la base de datos

Principalmente es necesario poder interactuar con bases de datos sin importar su

motor específico. Los principales requerimientos es este aspecto son:

Independencia del motor de base de datos.

Índices compartidos entre datos primitivos y descriptores de objetos 3D.

Almacenar tanto descriptores como objetos 3D.

Manejo de transacciones a nivel de objeto 3D.



4 Anexos

Documento de especificación de casos de uso:

Modelo de casos de uso EA_2011_11_26.rtf

Documento de especificación del modelo del dominio:

Modelo de dominio EA_2011_11_26.rtf

Modelo de especificación de requerimientos:

Modelo de requerimientos EA_2011_11_26.rft

Anexos%20del%20SRS/Modelo%20de%20casos%20de%20uso%20EA_2011_11_26.rtf

Anexos%20del%20SRS/Modelo%20de%20dominio%20EA_2011_11_26.rtf

Anexos%20del%20SRS/Modelo%20de%20requerimientos%20EA_2011_11_26.rtf



BIBLIOGRAFIA

[1] Wiegers, Karl. , Software Requirements Specification. Process Goodies 2002,

Disponible en http://www.processimpact.com/goodies.shtml

[2] Construx Software, Software Requirements Specification CXOne Standard, Construx

Software Builder, Inc, Noviembre 2002.

[3] IEEE (Institute of Electrical and Electronics Engineers), IEEE Recommended Practice

for Software Requirements Specificacitions, IEEE-SA Standards Board, Junio 1998.

[4] Java SE Technologies – Java Database Connectivity (JDBC) [homepage de Internet].

Copyright 1994-2007 Sun Microsystems, Inc. [citado 2007 Mar 25]. Disponible en:

http://java.sun.com/javase/technologies/database/index.jsp

[5] IEEE (Institute of Electrical and Electronics Engineers), IEEE Guide for Developing

System Requirements Specifications, IEEE-SA Standards Board, Abril 1996.

[6] Nuseibeh, B. et al, Requirements Engineering: A Roadmap, [citado 2007 Septiembre

07], Disponible en: http://www.doc.ic.ac.uk/~ban/pubs/sotar.re.pdf

[7] Pagina de Miguel Torres [homepage de Internet]. Bogotá. Ing. Miguel Eduardo

Torres Moreno MSc. Copyright - Miguel Torres 2007. [actualizado el 26 Feb 2007;

citado 2007 Septiembre 07]. Materias - Ingeniera de Software, Robertson, S. et. At.

Mastering the Requirements Process

[8] IronWorks, Especificación de Requerimientos De Software 7 Texas Poker, Primer

Semestre 2007, Pontificia Universidad Javeriana

[9] Barbacci, M. et al, Quality Attributes, Software Engineering Institute, Carnegie

Mellon University, December 1995

Arquitectura de un modulo I/O para objetos...

Documents

Transcript of Arquitectura de un modulo I/O para objetos...