Arquitectura de un modulo I/O para objetos...
Transcript of 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
Ingeniería de Sistemas PUJ 2
SRS: Arquitectura de un modulo I/O para objetos 3D
Lista de Tablas
Tabla 1 ..................................................................................................................................... 7 Tabla 2 ....................................................................................................................................10 Tabla 3 ....................................................................................................................................10 Tabla 4 ....................................................................................................................................12
Ingeniería de Sistemas PUJ 3
SRS: Arquitectura de un modulo I/O para objetos 3D
Lista de Ilustraciones
Figura Numero 1 ....................................................................................................................... 9 Figura Numero 2 ......................................................................................................................11
Ingeniería de Sistemas PUJ 4
SRS: Arquitectura de un modulo I/O para objetos 3D
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.
Ingeniería de Sistemas PUJ 5
SRS: Arquitectura de un modulo I/O para objetos 3D
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.
Ingeniería de Sistemas PUJ 6
SRS: Arquitectura de un modulo I/O para objetos 3D
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
Ingeniería de Sistemas PUJ 7
SRS: Arquitectura de un modulo I/O para objetos 3D
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.
Ingeniería de Sistemas PUJ 8
SRS: Arquitectura de un modulo I/O para objetos 3D
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.
Ingeniería de Sistemas PUJ 9
SRS: Arquitectura de un modulo I/O para objetos 3D
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
Ingeniería de Sistemas PUJ 10
SRS: Arquitectura de un modulo I/O para objetos 3D
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
Ingeniería de Sistemas PUJ 11
SRS: Arquitectura de un modulo I/O para objetos 3D
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
Ingeniería de Sistemas PUJ 12
SRS: Arquitectura de un modulo I/O para objetos 3D
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
Ingeniería de Sistemas PUJ 13
SRS: Arquitectura de un modulo I/O para objetos 3D
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.
Ingeniería de Sistemas PUJ 14
SRS: Arquitectura de un modulo I/O para objetos 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
Ingeniería de Sistemas PUJ 15
SRS: Arquitectura de un modulo I/O para objetos 3D
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