Emulador de Master System 2 corriendo bajo PlayStation Portable

1 Jorge García Flores EMULADOR DE MASTER SYSTEM 2 CORRIENDO BAJO PLAYSTATION PORTABLE Alumno: Jorge García Flores Tutor: Fernando Díaz Gómez Jorge García Flores 2 i Agradecimientos Ante todo quisiera agradecer el apoyo mostrado por mi familia para la realización y consecución de esta titulación, con el consiguiente aguante que han tenido que tener. Segundo, a mis amigos, en especial a Víctor Daniel Santos Gonzálvez, David Bravo y a Luis Miguel Martín Rodríguez. Además quisiera acordarme de ese amigo que me dio un poco de sabiduría en el mundo de la informática que es Sergio Ortega (este hombre es una fiera tanto en sistemas como en programación). También a mi tutor de Proyecto de Fin de Carrera, Fernando Díaz Gómez por toda su ayuda y que me ha asombrado con lo que puede llegar a saber sobre Informática en general. Y por último, aunque no por ello menos importante, a esos grandes compañeros que he conocido en la Escuela de Informática de Segovia y de lo cual estoy muy orgulloso de poder decir que son nuevas amistades para mí (Fátima Serna García, Yésica Valle, Manuel Rico López, etc.). Muchas gracias a todos vosotros. Cualquier sueño que merezca soñarse, es un sueño por el que luchar. Jorge García Flores ii iii Jorge García Flores Índice PARTE 1: ........................................................................................................... 1 INTRODUCCIÓN AL SISTEMA ............................................................................ 1 1.- INTRODUCCIÓN ........................................................................................... 2 1.1.- IDENTIFICACIÓN DEL PROYECTO............................................... 2 1.2.- ORGANIZACIÓN DE LA MEMORIA .............................................. 2 2.- DESCRIPCIÓN GENERAL ....................................................................... 5 2.1.- MOTIVACIÓN .................................................................................... 7 2.2.- OBJETIVOS ........................................................................................ 8 2.3.- FUNCIONALIDADES DEL PRODUCTO....................................... 10 2.4.- DESCRIPCIÓN DEL PRODUCTO ................................................. 12 2.4.1.- DISEÑO DE LA ESTRUCTURA DE LA APLICACIÓN ............ 12 2.5.- DESCRIPCIÓN DE LA NOMENCLATURA UTILIZADA ............ 16 2.6.- DESCRIPCIÓN DEL ENTORNO DE EJECUCIÓN DE LA APLICACIÓN ............................................................................................ 17 2.7.- TECNOLOGÍA EMPLEADA ........................................................... 24 2.8.- VISIÓN GLOBAL DE LA MASTER SYSTEM 2 ........................... 26 2.8.1.- CPU Z80 ..................................................................................... 27 2.8.2.- SISTEMA DE ENTRADA/SALIDA ......................................... 29 2.8.3.- SISTEMA DE MEMORIA ......................................................... 30 2.8.4.- PROCESADOR DE VÍDEO (VDP) ........................................... 35 2.8.5.- GENERADOR DE SONIDO PROGRAMABLE (PSG) ........... 36 2.8.6.- DISPOSITIVOS CONTROLADORES ...................................... 37 3.- METODOLOGÍA EMPLEADA .............................................................. 38 4.- PRESUPUESTO DE GASTOS ................................................................ 40 4.1.- CARACTERÍSTICAS DE LOS SISTEMAS SOFTWARE.............. 41 4.2.- PRINCIPALES FASES EN LA ELABORACIÓN DEL SOFTWARE .................................................................................................................... 41 4.3.- ESTUDIO ECONÓMICO DEL PROYECTO .................................. 42 Jorge García Flores iv 4.4.- CALENDARIZACIÓN DEL PROYECTO....................................... 57 PARTE 2: ......................................................................................................... 61 DESARROLLO DEL SISTEMA ............................................................................ 61 5.- REQUISITOS DEL SISTEMA ................................................................ 62 5.1.- REQUISITOS DE INFORMACIÓN ..................................................... 62 5.2.- REQUISITOS FUNCIONALES ....................................................... 69 5.3.- REQUISITOS NO FUNCIONALES ................................................. 71 5.3.1.- DEFINICIÓN DE ACTORES .................................................... 73 5.3.2.- CASOS DE USO ........................................................................ 74 5.4.- MATRIZ DE RASTREABILIDAD .................................................. 90 5.5.- RESUMEN ........................................................................................ 92 5.6.- GLOSARIO DE TÉRMINOS ............................................................ 95 5.7.- ÍNDICE DE TABLAS ....................................................................... 96 6.- ANÁLISIS DEL SISTEMA ..................................................................... 97 6.1.- DIAGRAMA DE PAQUETES .......................................................... 97 6.1.1.-UNIDAD PL_SND .................................................................... 100 6.1.2.-UNIDAD VIDEO ...................................................................... 100 6.1.3.- UNIDAD PL_PSP .................................................................... 101 6.1.4.- UNIDAD CTRL ........................................................................ 102 6.1.5.- UNIDAD MENU ...................................................................... 102 6.1.6.- UNIDAD EMUMAIN .............................................................. 103 6.1.7.- UNIDAD PL_UTIL .................................................................. 104 6.1.8.- UNIDAD UI.............................................................................. 104 6.1.9.- UNIDAD PL_MENU ............................................................... 106 6.1.10.- UNIDAD PL_FILE ................................................................. 109 6.1.11.- UNIDAD PL_INI .................................................................... 109 6.1.12.- UNIDAD PL_REWIND ......................................................... 110 6.1.13.- UNIDAD TYPES .................................................................... 111 6.1.14.- UNIDAD LOADROM ............................................................ 111 v Jorge García Flores 6.1.15.- UNIDAD STATE ................................................................... 112 7.- DISEÑO DEL SISTEMA ....................................................................... 112 7.1.- DEFINICIÓN DEL TAD ................................................................. 113 7.1.1CONSIDERACIONES ESPECIALES DE TAD....................... 128 7.2.- DIAGRAMA DE ESTRUCTURA .................................................. 131 7.4.- DISEÑO DE LA INTERFAZ DE USUARIO ................................. 136 8.- CUESTIONES DE IMPLEMENTACIÓN ............................................. 143 8.1.- JUSTIFICACIÓN DE LAS TECNOLOGÍAS UTILIZADAS ........ 145 8.2GENERACIÓN MAKEFILE ........................................................... 147 9.- DISEÑO DE LAS PRUEBAS DEL SISTEMA ..................................... 150 9.1.- PRUEBAS DE INSTALACIÓN ..................................................... 151 9.2.- PRUEBAS DEL SISTEMA ............................................................. 151 PARTE 3: ..................................................................................................... 161 CONCLUSIONES ....................................................................................... 161 10.- CONCLUSIONES Y FUTUROS TRABAJOS .................................... 162 10.1.- EVALUACIÓN ............................................................................. 162 10.1.1EVALUACIÓN DEL RENDIMIENTO .................................. 162 10.1.2.- EVALUACIÓN DE LA ROBUSTEZ .................................... 164 10.2.- CONSECUCIÓN DE LOS OBJETIVOS PLANTEADOS ........... 164 10.3.- ADQUISICIÓN DE NUEVOS CONOCIMIENTOS .................... 165 10.4.- POSIBLES AMPLIACIONES ...................................................... 167 11.- BIBLIOGRAFÍA .................................................................................. 169 APÉNDICES ................................................................................................ 171 APÉNDICE I: MANUAL DE INSTALACIÓN .......................................... 172 1.- COMPONENTES NECESARIOS ......................................................... 172 APÉNDICE II: MANUAL DE USUARIO .................................................. 180 1 PARTE 1: INTRODUCCIÓN AL SISTEMA Jorge García Flores 8 Es por tanto, que ya que al realizar un emulador de una computadora, eligiera para ello la primera videoconsola que tuve, y que fue la Master System 2 de Sega. De sus detalles se hablará más adelante para explicar su funcionamiento al igual de qué se compone dicha máquina. Otra de las motivaciones es que quería probarme a mí mismo para realizar un proyecto de esta envergadura, teniendo en cuenta que no es lo que se suele hacer como proyecto en la Escuela de Ingeniería Técnica de Informática de Gestión cuando un alumno propone un proyecto a un tutor. Siempre me ha gustado intentar superar mis límites y ver de lo que soy capaz de hacer. 2.2.- OBJETIVOS El objetivo del proyecto a realizar es la construcción de un emulador de la videoconsola Master System 2 de la empresa Sega, la cual fue lanzada al mercado en el año 1985, para poder ser ejecutada en una videoconsola PlayStation Portable (PSP) de la empresa Sony, la cual fue puesta a la venta en el año 2004. Como consecuencia de un análisis concienzudo, se tienen los siguientes objetivos concretos: • Ejecutar el emulador de la máquina Master System 2 con la videoconsola PSP (PlayStation Portable) desde una tarjeta de memoria Memory Stick. • Ejecutar los videojuegos disponibles de dicha videoconsola mediante emulación, realizando la carga de ellos. Dichos juegos se guardarán también en la Memory Stick en formato .rar. • Cambiar distintos parámetros en las opciones del emulador como puede ser la frecuencia de reloj de la PSP para poder ofrecer una buena emulación, controles, visualización de frames por segundo, etc. 9 Jorge García Flores Dicho de esta forma, es una explicación general, pero a continuación, se mostrará de forma totalmente detallada los objetivos del sistema [APUNTES INGENIERÍA DEL SOFTWARE 1 – FRANCISCO JOSÉ GONZÁLEZ CABRERA]: OBJ-01 Ejecutar emulador Master System 2 en PSP Versión 1.0 Autores Jorge García Flores Fuentes Descripción El sistema Sony Playstation Portable deberá ejecutar el emulador de la videoconsola Master System 2. Subobjetivos Ejecutar juegos en el emulador Configuración del emulador Importancia Imprescindible Urgencia Alta Estado Validado Estabilidad PD Comentarios Ninguno OBJ-02 Ejecutar juegos en el emulador Versión 1.0 Autores Jorge García Flores Fuentes Descripción El emulador de la videoconsola Master System 2 deberá ejecutar las ROMS. Subobjetivos Importancia Imprescindible Urgencia Alta Estado Validado Estabilidad PD Comentarios Ninguno Jorge García Flores 10 OBJ-03 Configuración del emulador Versión 1.0 Autores Jorge García Flores Fuentes Descripción Se podrá configurar el emulador para características de vídeo, sonido, controles, etc. Subobjetivos Importancia Imprescindible Urgencia Alta Estado Validado Estabilidad PD Comentarios Ninguno 2.3.- FUNCIONALIDADES DEL PRODUCTO A continuación, de forma detallada, se presentan y enumeran las funcionalidades disponibles por parte del producto desarrollado para el Proyecto Fin de Carrera. Dichas funcionalidades pueden ser divididas en dos grandes apartados dependiendo de a quién afecte. Esto es debido a que existen ROMS con las que se podrá realizar una serie de cosas y el contenedor para ejecutar el emulador, en el que se podrán realizar cambios en él. Además, existen una serie de consideraciones especiales que tratan de las informaciones que se crean que también serán descritas. En este momento se detallan de forma general, mostrándose más adelante una forma mucho más detallada mediante tablas [APUNTES INGENIERÍA DEL SOFTWARE 1 –FRANCISCO JOSÉ GONZÁLEZ CABRERA]. ROMS: Las funcionalidades que atañen a una ROM son las que se detallan a continuación de forma general.  Ejecutar ROM. 11 Jorge García Flores  Cargar partida de una ROM ejecutada previamente.  Guardar partida de una ROM ejecutada previamente.  Cambiar parámetros de una ROM ejecutada previamente. o Parámetro de Audio (diferentes frecuencias). o Parámetro de Vídeo. o Parámetro de Controles. o Parámetro de Sistema. o Parámetro de System. CONTENEDOR DEL EMULADOR: Las funcionalidades que se corresponden con el contenedor del emulador son las que se describen a continuación de una forma también general.  Menú principal.  Opciones del contenedor del emulador. o Parámetro de Vídeo. o Parámetro de Entrada (botones de la videoconsola PlayStation Portable). o Rendimiento de la videoconsola PlayStation Portable a través del contenedor para ejecutar el emulador. o Botón de cancelación de la consola PlayStation portable (hay que recordar que dependiendo de la región de la videoconsola (Asia-Norteamérica, Europa, el botón de cancelar será el botón X -equiso el botón O -círculo-). INFORMACIÓN: Jorge García Flores 12 Respecto a las funcionalidades que se corresponden a la información de la ROM, también se tratan de forma general en este apartado. Dichas funcionalidades son las siguientes.  Información de ROMS.  Información de los controles.  Información de las opciones.  Información de partida guardada correspondiente a una ROM.  Información del sistema.  Número máximo de partidas guardadas.  Cambio de opciones sin resetear el emulador. 2.4.- DESCRIPCIÓN DEL PRODUCTO En el actual apartado se realizará una descripción del producto que se ha desarrollado como Proyecto Fin de Carrera, tratado como un subapartado a su vez, el cual el Diseño de la Interfaz de Usuario. Respecto al Diseño de la interfaz de usuario se explicarán una serie de consideraciones que hay que tener en cuenta en toda interfaz que se desarrolle, y a su vez también se detallará cómo se encuentra estructurada la aplicación desarrollada para el Proyecto Fin de Carrera. 2.4.1.- DISEÑO DE LA ESTRUCTURA DE LA APLICACIÓN Lo primero que hay que hacer es explicar qué es una interfaz de usuario. Según [Wikipedia], la interfaz de usuario se define como el medio con que el usuario se comunica con una máquina, equipo o computadora (en nuestro caso la videoconsola PlayStation Portable), y comprende todos los puntos de contacto entre el usuario y el equipo. Por norma general suelen ser intuitivas (fáciles de entender) y fáciles de accionar. 13 Jorge García Flores En el producto desarrollado para el Proyecto Fin de Carrera se presenta una interfaz básica que será gráfica (GUI, Graphic User Interface) que incluye un menú con una serie de opciones mostrado todo a través del contenedor implementado y que podrá ser visualizado a través de la videoconsola PlayStation Portable. La interfaz usada es una interfaz de Software-Hardware, que establece un puente entre la máquina (PlayStation Portable) y el usuario, permitiendo a la máquina entender las instrucciones y al usuario el código binario de forma legible. Además hay que decir que en realidad la interfaz no se comunica solamente con la PlayStation Portable como máquina, sino también con la videoconsola emulada Master System 2, que hace las veces de un nuevo hardware, aunque se encuentre emulado mediante software. Añadir, que el diseño de las interfaces de usuario se han de centrar en la experiencia del usuario con las aplicaciones y los conocimientos que tengan adquiridos, por lo que pueden existir diversos tipos de usuarios y que engloban a un gran conjunto que va desde usuarios totalmente experimentados hasta usuarios no han tenido nunca una relación con un software, independientemente del tipo de aplicación que se realice. Por todo ello, una interfaz de usuario debe de cumplir una serie de requisitos, los cuales son los siguientes que se van a detallar de una forma breve. • Puesta en marcha y apagado: el producto desarrollado permite una puesta en marcha y apagado del emulador sin tener que apagar el sistema bajo el que está corriendo, por lo que está realizado de una forma totalmente eficiente sin que el usuario tenga la molestia de apagar la PlayStation Portable para poder ejecutar otra aplicación • Control de las funciones manipulables del equipo: en realidad lo que se manipula son las funciones del contenedor, no las funciones de la máquina emulada, ya que sería algo prácticamente imposible mediante software (de forma física sí que se podría, como por ejemplo introducir en un sistema físico Master System 2 una visualización Jorge García Flores 14 mediante RGB y no analógico como se encontraba implementado). • Manipulación de archivos y directorios: se permite CRUD (crear, leer, modificar y borrar) directorios, así como ROMS, pero en este caso se tiene que hacer conectando la PlayStation Portable a un equipo (ordenador de sobremesa, notebook, laptop), ya que todo se encuentra en la tarjeta de memoria Memory Stick. • Herramientas de desarrollo de aplicaciones: en nuestro caso esto no es necesario, ya que lo único que se va a hacer es ejecutar una máquina emulada (Master System 2) a través de un contenedor y que se ejecutará en una PlayStation Portable para poder ejecutar a su vez dicha máquina emulada videojuegos creados para ella. • Comunicación con otros sistemas: nuestra aplicación se comunicará en realidad con dos sistemas, uno físico (PlayStation Portable) y otro lógico (Master System 2), que a su vez es pseudofísico por las características que contiene. Además hay que indicar que la máquina física que ejecuta el software, puede comunicarse con otras máquinas a través de internet mediante wi-fi con una conexión del tipo ad-hoc y también con ordenadores mediante cable USB. • Información de estado: el software desarrollado permite una información acerca del estado de la batería de la PlayStation Portable, la temperatura que tiene y la hora del sistema. • Configuración de la propia interfaz y entorno: la interfaz puede configurarse según una serie de parámetros que modifican el contenedor de la aplicación. • Intercambio de datos entre aplicaciones: se realiza un intercambio de datos entre aplicaciones, ya que mediante el contenedor de la aplicación podemos elegir una ROM y ser 15 Jorge García Flores ejecutada en otra aplicación, que en este caso es el de la máquina emulada Master System 2. • Control de acceso: no se ha considerado necesario un control de acceso a la aplicación por dos motivos. El primero es debido a la naturaleza del desarrollo de la aplicación en la escena homebrew y segundo, no existe diferenciación de usuarios. • Sistema de ayuda interactivo: existen una serie de mensajes que aparecen de forma dinámica en caso de realizar unas acciones por parte del usuario y que permiten una ayuda para tener una experiencia totalmente satisfactoria de la aplicación. Según todo esto, se puede ver que el usuario no va a tener ningún problema con la aplicación, aunque se haya desarrollado para una máquina de propósito específico como es la videoconsola PlayStation Portable, ya que contiene las siguientes consideraciones:  Presenta una claridad y una estética acordes debido a su sencillez de menús y desplazamiento a través de ellos.  Fácil de utilizar con los controles de PlayStation Portable.  Es perfectamente funcional, haciendo lo que tiene que hacer y siendo diseñado para ello.  Presenta una legibilidad clara en todas las opciones que presenta y el sistema de directorios que se ha creado, por lo que hay una probabilidad muy pequeña de perderse, sobre todo una vez que el usuario se ha familiarizado con el producto.  Es rápido a la hora de cargar la aplicación, así como a la hora de cargar los videojuegos la consola emulada, ya que todo se encuentra en una tarjeta de memoria, al contrario que los videojuegos originales para PlayStation Portable Jorge García Flores 16 que se encuentran en un UMD, por lo que su acceso es mucho más rápido que una unidad lectora.  Todo lo que se ha creado en la interfaz es suficientemente significativo para un usuario, tanto los mensajes que se crean de ayuda, como la visualización de la propia interfaz. Como conclusión, decir que la interfaz creada presenta todas las especificaciones que han sido definidas como un estándar. 2.5.- DESCRIPCIÓN DE LA NOMENCLATURA UTILIZADA En el apartado actual se debe presentar una descripción acerca de una serie de términos que se han ido utilizando a lo largo del documento para una familiarización con ellos a modo de glosario. Esto es debido a que existen términos específicos que corresponden a aspectos no tratados a lo largo de la enseñanza de la Ingeniería Técnica de Informática de Gestión y deben ser explicados para que todos los usuarios de la documentación, así como de la aplicación sepan de qué se está hablando. Esta nomenclatura se desarrollará para una forma más cómoda del lector en un orden alfabético, presentándose en una tabla que contendrá dos columnas. La primera corresponde al término y la segunda será su definición correspondiente de una manera amena, pero a la vez rigurosa. TÉRMINO DESCRIPCIÓN Master System 2 Videoconsola de tercera generación, la cual es de 8 bits, de sobremesa y es producida por SEGA. Memory Stick Tarjeta de memoria flash cuyo funcionamiento permite guardar datos, en este caso de partidas de juegos de la consola Playstation Portable, y emuladores y los propios juegos de los 17 Jorge García Flores emuladores, además de fotos, vídeos, música, etcétera para ser ejecutados dentro de la Playstation Portable. Playstation Portable Videoconsola de séptima generación, la cual es de 32 bits, portátil y es producida por SONY. ROM Representa la memoria en la que está almacenado un juego que podrá ser ejecutado por la Master System 2. iROM Juego comenzado que se caracteriza por ser una ROM más el estado en ejecución de una partida jugada anteriormente y que ha sido guardada. 2.6.- DESCRIPCIÓN DEL ENTORNO DE EJECUCIÓN DE LA APLICACIÓN El sistema desarrollado se basa en una Arquitectura de Máquinas Virtuales. Los motivos de por qué se utiliza este tipo de arquitectura y no otra los iré detallando a lo largo del presente apartado, pero antes de hacerlo, primero se debe definir y explicar qué es una máquina virtual para entender las razones de esta arquitectura elegida. La definición de máquina virtual según [Wikipedia] es un software que simula una computadora y puede ejecutar programas como si fuese una computadora real. Una característica esencial de las máquinas virtuales es que los procesos que ejecutan están limitados por los recursos y abstracciones proporcionadas por ellas, es decir, que estos procesos no pueden escaparse de esta “máquina virtual”. Por parte de la empresa vmware nos dice que una máquina virtual es un contenedor de software perfectamente aislado que puede ejecutar sus propios sistemas operativos como si fuera un ordenador Jorge García Flores 24 Otra consideración a tener en cuenta es por qué se usa la conexión entre dos máquinas PlayStation Portable mediante ad-hoc. Esto es debido a que PlayStation Portable tiene una conexión inalámbrica wi-fi 802.11b y es la forma más fácil de conectarla a una red sin necesidad de usar un punto de acceso, por lo que en cuanto una máquina PlayStation Portable se conecta a la red, puede compartir la conexión con los demás equipos de esa red de una manera tradicional, mientras que una conexión por infraestructura requiere de un punto de acceso. 2.7.- TECNOLOGÍA EMPLEADA Se ha usado una serie de herramientas para desarrollar la aplicación en el presente Proyecto Fin de Carrera y que son las siguientes: • Hardware: o Ordenador de sobremesa. o Sony PlayStation Portable. o Tarjeta de memoria Memory Stick. • Software o DevC++ IDE como entorno de desarrollo (IDE) para programar en C y su correspondiente compilador. o PSPsdk como kit de desarrollo para PlayStation Portable y sus correspondientes librerías. o Kit de Programación PSP 3.0 que es un compilador para crear ejecutables EBOOT.PBP de PlayStation Portable y además contiene:  Oracle VM Virtual Box 4.2.12. • Distribución Debian. 25 Jorge García Flores o Memoria Base: 4GB. o Procesadores: 8. o Memoria de vídeo: 12 MB. o Puerto SATA: Normal, 14GB.  PSPdev Win32 + SDK  Librería devkitARm + SDK.  devkitPSP Revisión 9.  Librerías: • SDL. • SDL_MIXER. • JPEG. • LIBpsp2d. • PSPGL. • LibbulletML. • Lib_Tremor. • LibPng. • Zlib. • LibMad, • OSlib. • Freetype. • OGG. • PSPToolChain. Jorge García Flores 26 o StarUML 5.0 para el modelado del diseño de la aplicación usando el lenguaje unificado de modelado UML. o GoldWave 4.26: para realizar el sonido de la aplicación en el menú del Sistema Operativo de la videoconsola PlayStation Portable, XMB (Xross Media Bar). o Atrac3: librería para la generación de sonido con una compresión de formato at3, el cual es sólo compatible con sistemas Sony y que es cerrado. o Oracle VM Virtual Box 4.2.12: aplicación de Oracle para la ejecución de diferentes Sistemas Operativos mediante una máquina virtual. o Debian: distribución Linux para la compilación de los ficheros implementados con el SDK para la videoconsola PlayStation Portable. 2.8.- VISIÓN GLOBAL DE LA MASTER SYSTEM 2 La videoconsola Master System 2 alberga dentro de ella una serie de procesadores de propósito específico, junto con un conjunto de elementos hardware para acondicionar las señales de comunicaciones entre todos sus componentes. La CPU de la máquina es el microprocesador Z80A, que para ser liberado de carga, la Master System 2 dispone de otros dos procesadores de propósito específico. El primero de ellos es el procesador de vídeo, variante del TMS9918 de Texas Instruments, encargado de realizar varios efectos por hardware como son escalados, detección de colisiones, doble capa de dibujado, etc.; proporcionando una resolución de 256x192 píxeles. El segundo procesador es el generador de sonido que corresponde a un chip SN76489 de Texas Instruments, capaz de generar 27 Jorge García Flores tres canales independientes de sonido y un cierto canal especializado en ruido. Aunque la videoconsola Master System 2 sólo incorpora 8 Kbyte de memoria RAM, los cartuchos pueden llegar a albergar hasta un Mbyte de memoria, la cual será direccionable por medio de mapeados de memoria. Por último, de forma externa a la Master System 2, es posible conectar una serie de dispositivos controladores (periféricos) para interactuar con la misma, como son los control pad, pistolas de luz, gafas tridimensionales y otros dispositivos variados. Todo esto se puede consultar en [http://www.smspower.org/Development/Documents] 2.8.1.- CPU Z80 En este apartado, se detallará la arquitectura del microprocesador de la Master System 2, el Z80A. Éste es un procesador CISC (Complex Set Instruction Code) diseñador para ser compatible con las aplicaciones realizadas para el procesador 8080 de Intel, compartiendo el mismo juego de instrucciones, conteniendo los mismos códigos de operación y al cual añade una serie de instrucciones para nuevos programas para que no tengan que mantener una compatibilidad. En el caso de la videoconsola Master System 2, está conectado a un reloj externo que funciona a 3.579545 MHz, llevando la temporización del resto de componentes del hardware de la videoconsola. Jorge García Flores 28 En la figura se puede observar que el microprocesador incorpora un bus de datos de 8 bits, limitando el tamaño de los datos intercambiados con los periféricos y memoria de un byte, y un bus de direcciones de 16 bits que supone un máximo de 65.536 palabras de memoria direccionables. Por otro lado, tiene dos espacios de direccionamiento de memoria y de E/S, pudiéndose direccionar la misma cantidad de unidades en cada uno de ellos. Los 26 registros que contiene son los siguientes: • B, C, D, E, H, L, B’, C’, D’, E’, H’, L’: registros de 8 bits que pueden agruparse de dos en dos para formar registros de 16 bits de la forma BC, DE, HL, B’C’, D’E’ y H’L’. Sólo son accesibles a la vez 6 de ello, pues se encuentran divididos en dos bancos intercambiables por medio de unas instrucciones específicas de cambio de banco. • A, F, A’, F’: registros de 8 bits que sólo son accesibles al mismo tiempo dos de ellos. El registro A es un registro de tipo acumulador el cual siempre será uno de los operandos 29 Jorge García Flores de la ALU (Unidad Aritmético Lógica). En el registro F se encuentran los flags de la máquina para poder guardar su estado. • PC: contador de programa que apunta a la dirección de la siguiente instrucción a ejecutar, siendo de 16 bits. • SP: puntero de pila, la cual apunta a la primera dirección libre de la pila de ejecución y que es también de 16 bits. • IX, IY: registros de 16 bits usados como dirección base para instrucciones que hacen uso de vectores. Existe una mini ALU que sólo sirve para sumarle un dato de 8 bits a estos registros y volcar el resultado al bus de direcciones. • I: registro de 8 bits usado para el tratamiento de interrupciones. • R: registro de 8 bits usado como salida para refrescar memorias externas y también como generador de números pseudoaleatorios. • W, Z: registros invisibles para el programador utilizados para almacenar resultados temporales al ejecutar ciertas instrucciones del procesador. 2.8.2.- SISTEMA DE ENTRADA/SALIDA Como se ha comentado anteriormente, el microprocesador Z80A tiene un bus de direcciones de 16 bits, pudiendo direccionar hasta 65.536 palabras de un byte de longitud. Por ello, el Z80A es capaz de seleccionar en un momento dado, mediante una señal, si comunicarse con dispositivos de E/S o memoria., por lo que permite el uso de todo el espacio direccionable para cada uno de los dos subsistemas. A pesar del espacio de E/S tan grande del que se dispone y que proporciona el microprocesador Z80A de la videoconsola Master Jorge García Flores 30 System 2, sólo hace uso de una pequeña cantidad de estos puertos de E/S, donde se encuentran conectados una serie de periféricos externos al microprocesador. 2.8.3.- SISTEMA DE MEMORIA La videoconsola Master System 2 dispone de 8 Kbyte de memoria RAM que se encuentran mapeados a partir de la dirección 0xc000, pero que también son accesibles desde la dirección 0xE000 (conocido como RAM duplicada). El sentido de tener la memoria RAM duplicada es que las cuatro últimas direcciones de memoria (0xFFFC0xFFFF) tienen en ellas mapeados registros de sólo escritura (registros de marco) que no pueden leerse por sí mismos, pero sí es posible leer direcciones equivalentes en la otra zona de la memoria RAM (0xDFFC0xDFFF) para obtener su valor. Al iniciarse la Master System 2, en la zona inferior de su memoria se encuentra una pequeña ROM de 8 Kbyte que contiene la BIOS y que será encargada de inicializar ciertos registros y copiarse a sí misma a la memoria RAM. Pero si encuentra un cartucho introducido en la ranura del mismo, le cede el control, mapeando la ROM del cartucho a partir de la dirección 0x0000. 31 Jorge García Flores Para cargar la ROM del programa sólo se dispone de 48 Kbyte de memoria direccionables. Esto es así físicamente y de este modo se cargan los programas de hasta 32 Kbyte de memoria, pero como hay programas que pueden llegar hasta el Mbyte de memoria, ahí entran en juego los mapeadores de memoria. Jorge García Flores 32 33 Jorge García Flores Al usar mapeadores de memoria se dividen los 64 Kbyte direccionables por el procesador en 4 marcos de 16 Kbyte cada uno numerados de 0 a 3 (de direcciones bajas a altas). Así mismo, la ROM del programa en cuestión también se dividirá en tantos bancos de 16 Kbyte como sea necesario para cubrir todo su tamaño. Mediante los registros de marco, el programa podrá seleccionar qué banco de la ROM mapear en cada momento en qué marco de memoria (del 0 al 2, a excepción del 3 que se encuentra ocupado por la memoria RAM), posibilitando de este modo el acceso a cualquier tamaño de memoria. Jorge García Flores 40 Otras con consideraciones a tener en cuenta en la fase de diseño es que se sigue una guía por medio de casos de uso, permitiendo el desarrollo de conceptos definidos con anterioridad en la fase de requisitos y posterior desarrollo del software a implementar. La desventaja es que se destina un 75% de recursos al mantenimiento y que cualquier error detectado en la etapa de prueba conduce necesariamente al rediseño y una nueva implementación del código, aumentando los costes del desarrollo del proyecto. 4.- PRESUPUESTO DE GASTOS En el actual apartado se realiza una descripción de la estimación del coste económico asociado a la realización del desarrollo del Proyecto Fin de Carrera de nombre “Emulador de Master System 2 corriendo bajo PlayStation Portable”, pero primero se debe hacer un inciso en que los sistemas software tienen unas características especiales que les hacen distintos del resto de proyectos de otras ingenierías. Para ello, este apartado se divide a su vez en otros tres apartados que serán descritos a continuación. 41 Jorge García Flores 4.1.- CARACTERÍSTICAS DE LOS SISTEMAS SOFTWARE Según se ve en [APUNTES INGENIERÍA DEL SOFTWARE 1 –FRANCISCO JOSÉ GONZÁLEZ CABRERA] y [APUNTES INGENIERÍA DEL SOFTWARE 2 –LUIS EZEQUIEL HERNANZ ALBERTOS, ENRIQUE CARBALLO] es que el software no se fabrica, sino que se desarrolla. Esto quiere decir que los costes del software no se deben a la fabricación del producto, ya que el software es intangible, sino a las horas empleadas en la creación del producto desarrollado. Otra característica es que el software al ser intangible no se degrada, es decir que no se rompe, pero sí que se vuelve anticuado, por lo que hay que crear nuevas modificaciones al software ya desarrollado, conllevando a una serie de errores y aumento de costes debido a que aumenta la complejidad en el desarrollo del software, sobre todo en aquellos productos que han sido desarrollados con un fuerte acoplamiento, por lo que su cohesión tiende a ser menor. Una nueva característica que difiere a un proyecto de ingeniería clásica es el mantenimiento, pues al no romperse el software, no necesita de “nuevas piezas físicas”, pero el fallo en el software puede llegar a ser más grave, ya que puede ser debido a un error en una etapa temprana del desarrollo y que no se ha tenido en cuenta hasta mucho más tarde. Es por ello, que el mantenimiento es mucho más complejo en el software que en cualquier otro producto realizado, aumentando su coste enormemente. 4.2.- PRINCIPALES FASES EN LA ELABORACIÓN DEL SOFTWARE En este apartado se abordan las principales fases que contiene el desarrollo de todo producto software. • Objetivos necesarios: se detallan los objetivos que abordará el producto software y lo que aportará a los usuarios, Jorge García Flores 42 definiendo funcionalidades del sistema y la forma de utilizar dicho sistema. • Especificaciones del Sistema: delimitación precisa del sistema y descripción del uso del mismo de distintas maneras por parte de los usuarios finales. • Análisis: proceso automatizado para analizar el comportamiento del software. Con ello se pretende mejorar el software en cuestiones de correctitud, optimización y seguridad, ya sea mediante análisis dinámico o análisis estático del software. • Diseño: determinación de la manera de resolver el problema planteado y que ha sido estudiado en la fase de análisis, proponiendo para ello soluciones modelando el comportamiento del sistema y posterior implementación. • Implementación: creación de las estructuras y algoritmos desarrollados en la fase de diseño mediante la codificación con algún lenguaje de programación. • Pruebas y verificación: fase en la que se asegura que el software se comporta de acuerdo a las especificaciones y objetivos que se han detallado sin cometer errores en el diseño y en la implementación. • Documentación: fase en la que se redacta de forma clara y concisa todo lo referente al desarrollo del producto software, así como los manuales destinados a los diferentes usuarios del mismo producto software. 4.3.- ESTUDIO ECONÓMICO DEL PROYECTO El presente apartado se centra en el estudio económico, con su estimación de costes mediante un estudio realizado de forma orientativa con el que poder hacer frente a los costes que se producen en el desarrollo del producto software, siendo este caso el Proyecto Fin de 43 Jorge García Flores Carrera con el nombre de “Emulador de Master System 2 corriendo bajo PlayStation Portable”. Para ello, se desglosará el estudio mediante diferentes etapas en la elaboración del desarrollo del proyecto, mostrándose la influencia de las etapas en el coste total del producto. Así mismo, se detallará mediante los puntos de función y el modelo constructivo de costes COCOMO la estimación del coste de dicho proyecto en esfuerzo y tiempo requerido. Se ha elegido un equipo de tres personas compuesto por los siguientes miembros:  Jefe de Proyecto que se encargará de una serie de tareas que se verán en la calendarización del proyecto.  Analista, encargándose de las fases de diseño y análisis.  Programador que se encarga de la codificación del proyecto.  Parte 1Estimación utilizando Puntos de Función: La métrica del punto de función es un método en ingeniería del software para medir el tamaño del software. Pretende medir la funcionalidad entregada al usuario independientemente de la tecnología utilizada para la construcción y explotación del software, y también ser útil en cualquiera de las fases de vida del software, desde el diseño inicial hasta la explotación y mantenimiento. Existen diferentes metodologías de medición, de las cuales la más popular es la mantenida por el International Function Point Users Group (IFPUG). Tradicionalmente se ha medido el tamaño del software mediante distintas métricas: recuento de las líneas de código, número de programas fuente, o técnicas similares, que no resultan aceptables como una buena práctica profesional, porque: • Su resultado depende fuertemente del entorno técnico y el lenguaje de programación utilizado • Varía en función de la pericia de cada programador y del uso de normas y metodologías Jorge García Flores 44 • No resultan significativas al usuario ni a la dirección Cuando se trata de establecer métricas de productividad y calidad en la construcción de software, o realizar estimaciones de coste y duración, es imprescindible disponer de una medida fiable y comprensible del tamaño de lo que se construye. La tabla que usaremos para realizar la práctica será una que se usó en la asignatura de Ingeniería del Software 1 y que se muestra a continuación: Factores de Complejidad 0-5 Factores de Complejidad 0-5 Comunicación de datos 3 Funciones distribuidas 0 Rendimiento 5 Configuraciones fuertemente utilizadas 2 Frecuencia de transacciones 4 Entrada on-line de datos 0 Diseño para la eficiencia del usuario final 3 Actualizaciones on-line 0 Procesos complejos 1 Reusabilidad 1 Facilidad de instalación 5 Facilidad de operación 2 Instalación en múltiples lugares 0 Facilidad de cambio 1 Parámetro Complejidad baja Complejidad media Complejidad alta Entradas x3 x4 x6 Salidas x4 x5 x7 Ficheros internos x7 x10 x15 Ficheros externos x5 x7 x10 Consultas externas x3 x4 x6 Para hallar los puntos de función, debemos seguir una serie de pasos: 45 Jorge García Flores 1.- Identificar el número de elementos y complejidad: • Entradas:  Número máximo de partidas guardadas  Cambio de opciones sin resetear el emulador  Cambiar sistema  Cambiar audio  Cambiar vídeo  Cambiar system • Salidas:  Información de la ROM  Información de los controles  Información de las partidas guardadas  Información de batería, temperatura y hora actuales • Ficheros externos:  Cargar ROM  Guardar Juego • Ficheros internos: • Cuestiones externas: 2.- Hallamos los puntos de función sin ajustar (PFNA): • Total de entradas = 6 • Total de salidas = 4 • Total de ficheros externos = 2 • Total de ficheros internos = 0 • Total de cuestiones externas = 0 Existen seis entradas, cuyas complejidades son las que se explican a continuación. El número máximo de partidas guardadas nos indica que podremos guardar hasta 10 partidas de una misma ROM, siendo este proceso de complejidad alta, ya que hay que interactuar con el estado en el que se encuentra la partida y guardarlo en una tarjeta de memoria Memory Stick para poder acceder al estado de la partida cuando se quiera más adelante. La complejidad del proceso cambio de opciones sin resetear el emulador consiste en cambiar una serie de parámetros del contenedor del emulador y guardarlo en la tarjeta de memoria Memory Stick, pero el emulador no se debe apagar, sino que Jorge García Flores 46 en cuanto se cambien las opciones, debemos seguir en el mismo lugar en el que nos encontráramos anteriormente al realizar los cambios, por lo que es alta su complejidad. A continuación, el proceso de cambiar sistema tiene una complejidad media, ya que cambiamos los parámetros del contenedor del emulador y deben ser guardados en la Memory Stick. Tanto cambiar audio, como cambiar vídeo y cambiar system tienen la misma complejidad media, debido a que lo que se hace es interactuar con la PlayStation Portable y el contenedor para que esas modificaciones se reflejen en las ROMS y el contenedor del emulador y también deben guardarse sus cambios en la Memory Stick. Respecto a las salidas, todas las complejidades son medias. La información de la ROM contiene el nombre de la ROM, además deberá ser guardado todo en una tarjeta de memoria Memory Stick. La información de los controles guarda la información correspondiente al mapeo de los botones para poder manejar las ROMS y movernos por el menú, teniendo que estar todo guardado en la Memory Stick. La información de las partidas guardadas nos guarda en la Memory Stick la información de una ROM que tiene un estado de juego guardado. Por último, la información de la batería, temperatura y hora actuales nos muestra información acerca del estado de la batería (medida en percentiles), la temperatura y la hora actual realizando llamadas al sistema de la PlayStation Portable que nos dice esa información. A continuación tenemos los ficheros externos. En nuestro caso existen dos procesos que son Cargar ROM y guardar Juego. La complejidad de las entradas es alta para cargar ROM y guardar ROM, ya que son procesos muy complejos de realizar al tener que interactuar con la tarjeta de memoria Memory Stick, el emulador de la Master System 2 y la consola PlayStation Portable. Además cargar ROM sirve tanto para ejecutar un juego la primera vez como para seguir una partida desde el lugar donde nos encontrábamos anteriormente en el juego. Respecto a guardar Juego, también su complejidad es alta porque tenemos que guardar el estado de donde nos encontremos en la ROM con toda la información que conlleva. 47 Jorge García Flores Hay que tener en cuenta que no tenemos ficheros lógicos internos, ni consultas externas, ya que no existe una base de datos en nuestro sistema y no hay transacciones con ella al no existir, por lo que al no existir una base de datos no hay ficheros lógicos internos y al no haber dicha base de datos, no se realizan consultas externas. Calculamos el PFNA: PFNA= 2 in x6 + 4 in x4 + 4 out x5 + 2 fle x10 = 68 Ahora calculamos el factor de ajuste, siendo ΣFi la suma de los factores de complejidad: FA= (0'01xΣFi) + 0'65 = (0'01x27) + 0'65 = 0'92 Por último, calcularemos los puntos de función ajustados usando los PFNA y el FA de la siguiente manera: PF= FAxPFNA = 0'92x68 = 62’56  Parte 2Estimación usando COCOMO: El Modelo Constructivo de Costes (o COCOMO, por su acrónimo del inglés COnstructive COst MOdel) es un modelo matemático de base empírica utilizado para estimación de costes de software. Incluye tres submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado. Este modelo fue desarrollado por Barry W. Boehm a finales de los años 70 y comienzos de los 80, exponiéndolo detalladamente en su libro "Software Engineering Economics". Pertenece a la categoría de modelos de subestimaciones basados en estimaciones matemáticas. Está orientado a la magnitud del producto final, midiendo el "tamaño" del proyecto, en líneas de código principalmente. Podremos usar uno de los tres siguientes modelos: • Modelo orgánico: un pequeño grupo de programadores experimentados desarrollan software en un entorno familiar. El tamaño del software varía desde unos pocos miles de Jorge García Flores 48 líneas (tamaño pequeño) a unas decenas de miles (medio). • Modelo semilibre: corresponde a un esquema intermedio entre el orgánico y el rígido; el grupo de desarrollo puede incluir una mezcla de personas experimentadas y no experimentadas. • Modelo rígido: el proyecto tiene fuertes restricciones, que pueden estar relacionadas con la funcionalidad y/o pueden ser técnicas. El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla. Al ser un proyecto el que se va a realizar muy complejo existiendo fuertes restricciones y una gran innovación tecnológica, así como una interacción entre un sistema que no es una computadora de propósito general, sino una de propósito específica (PlayStation Portable) con un sistema que emula otra computadora de propósito específica (Master System 2), que en este caso es de mayor antigüedad y que tiene un contenedor que hace posible el poder usar dicho emulador, el modelo que se usa es el rígido: MODO a b c d Orgánico 2'4 1'05 2'5 0'38 Semilibre 3 1'12 2'5 0'35 Rígido 3'6 1'2 2'5 0'32 La tabla de líneas de código usando un lenguaje se muestra también a continuación: 49 Jorge García Flores Lenguaje LDC/PF Ensamblador 320 C 150 Cobol 106 Pascal 91 Basic 64 PCL 64 Java 53 C++ 29 Sabiendo que los puntos de función ajustados nos han dado el resultado de 62’56 y que el lenguaje que se utilizará será C, debido a que es un lenguaje con el que se puede interactuar a un nivel casi bajo, aun siendo de alto nivel dicho lenguaje de programación y es de los pocos que nos permite una programación en lenguaje ensamblador para poder interactuar con los sistemas en cuestión que se relacionan entre ellos, hallaremos el número de líneas de código del programa: LDC= Líneas de código del lenguaje x PF = 150x62’56 = 9384 LDC ≈ 9’384 KLDC Jorge García Flores 56 − Fase de Diseño − Diagrama de Casos de Uso: − Duración: 3 días − Persona que se ocupa: Analista − Horas por día: 8 horas − Diagrama de Paquetes: − Duración: 1 días − Persona que se ocupa: Analista − Horas por día: 8 horas − Diagrama de estructura: − Duración: 1 días − Persona que se ocupa: Analista − Horas por día: 8 horas − Implementación: − Duración: 60 días − Persona que se ocupa: programador − Horas por día: 8 horas − Pruebas: − Duración: 15 días − Persona que se ocupa: programador − Horas por día: 8 horas Por lo tanto, el costo del proyecto resultante será: − Documentación= 9386’13 € − Especificación de requisitos= 381’03 Euros − Objetivos del sistema= 0 € − Requisitos no funcionales= 0 € 57 Jorge García Flores − Requisitos de información= 0 € − Requisitos funcionales= 0 € − Diseño= 381’03 € − Diagrama de Clases= 1008'0 € − Diagrama de Secuencia= 1872'0 € − Diagrama de Casos de Uso= 864'0 € − Diagrama de Estados= 720'0 € − Diagrama de Objetos= 720'0 € − Implementación= 407’03 € − Pruebas= 0 € − Ordenadores= 116’23x3 = 348’69 € − Conexión a Internet: 24’90x5 = 124’50 € − Impresora: 119’00 € − PlayStation Portable: 66’00 € − Windows 7:129’90x3 = 389’70 € − StarUML: 0’00 € − Microsoft Office 2007: 119’90x3 = 359’70 € − DevC++ IDE: 0’00 € − Oracle VM Virtual Box 4.2.12: 0’00 € − Debian: 0’00 € − Kit de Programación PSP 3.0: 0’00 € − Total= 12462’81 € 4.4.- CALENDARIZACIÓN DEL PROYECTO En este apartado se mostrará el desarrollo de las fases del proyecto, así como los recursos asignados a las distintas fases. Todo ello ha sido realizado con la herramienta de Open Project. Primero se verá el Diagrama de Gantt con las fases realizadas Jorge García Flores 58 en una tabla, para a continuación ver los recursos y por último mostrar el Diagrama de Pert. Se puede ver en la primera parte del Diagrama de Gantt las fechas perfectamente en las que el Proyecto Fin de Carrera comenzó y termina, así como la duración de cada fase y los recursos asignados a cada fase. 59 Jorge García Flores En la segunda parte del Diagrama de Gantt vemos la evolución de las fechas según las tareas de las fases que se realizan, así como los recursos que han sido asignados, todo ello mediante barras. En esta tabla se ven todos los recursos existentes en la realización del proyecto, tanto materiales como humanos, con sus costes por uso en el caso de los recursos materiales y las tasas estándar y de sobretiempo en los recursos humanos. Jorge García Flores 60 En este diagrama, el cual es llamado Diagrama de Pert o Diagrama de red se pueden ver todas las fases, con sus fechas y la duración de cada una de ellas y cómo se encuentran relacionadas entre ellas. 61 Jorge García Flores PARTE 2: DESARROLLO DEL SISTEMA Jorge García Flores 62 5.- REQUISITOS DEL SISTEMA El análisis del sistema es el proceso del estudio de las necesidades de los usuarios para llegar a una definición de requisitos del sistema, así como el refinamiento de dichos requisitos. Dicho esto, la definición de requisito es la que sigue a continuación Un requisito es una condición o capacidad que necesita el usuario para resolver un problema o conseguir un determinado objetivo. El modelo de análisis constituye una abstracción resumida y precisa de lo que debe hacer el sistema que se va a desarrollar y no la forma en cómo se desarrollará, es decir, nos dice el qué hacer pero no el cómo hacerlo. Esto es importante, ya que al no incluirse en esta parte estructuras de la implementación, un buen modelo puede ser visto por personas expertas de la aplicación a desarrollar que no sean programadores. Al proponer el proyecto llamado “EMULADOR DE MASTER SYSTEM 2 CORRIENDO BAJO PLAYSTATION PORTABLE” se fijaron una serie de requisitos funcionales para la integración de la aplicación, así como de requisitos no funcionales, casos de uso, requisitos de información y definición de actores que se pasará a desglosar a continuación. 5.1.- REQUISITOS DE INFORMACIÓN Los requisitos de información que se encuentran presentes en el proyecto corresponden a dos grupos diferenciados. Estos grupos son:  Información que atañe a las ROMS.  Información acerca del contenedor del sistema. Como se puede ver en las siguientes tablas, se desglosa de forma detallada y de acuerdo al estándar exigido en la asignatura de Ingeniería del Software 1 los siguientes requisitos de información. 63 Jorge García Flores IRQ-01 Información de las ROMS Versión 1.0 Autores Jorge García Flores Fuentes Objetivos asociados OBJ–01 Ejecutar emulador Master System 2 en PSP. OBJ–02 Ejecutar juegos en el emulador. Requisitos asociados UC–1_01 Menú_Principal UC–1_02 Cargar_ROM UC–1_03 Cargar_Guardar_Juego UC–1_10 Sistema UC–1_11 Audio UC–1_12 Vídeo2 UC–1_13 System Descripción El sistema deberá almacenar la información correspondiente a las ROMS, así como la carpeta en la que se encuentran. ROM: representa la memoria en la que está almacenado un juego que podrá ser ejecutado por la Master System 2. Datos específicos _ Nombre de la ROM Carpeta en que se encuentran las ROMS Tiempo de vida Medio Máximo 7 años 10 años Ocurrencias simult. Medio Máximo Importancia Alta Urgencia Media Estado Validado Estabilidad Alta Comentarios Ninguno Jorge García Flores 64 IRQ-02 Información de los controles Versión 1.0 Autores Jorge García Flores Fuentes Objetivos asociados OBJ–01 Ejecutar emulador Master System 2 en PSP. OBJ–03 Configuración del emulador. Requisitos asociados UC–1_09 Controles Descripción El sistema deberá mostrar y almacenar la información correspondiente a os controles con los que se podrá manejar los juegos ejecutados por el emulador, así como los controles que manejan el contenedor del emulador. Datos específicos _ Nombre de los controles Tiempo de vida Medio Máximo 7 años 10 años Ocurrencias simult. Medio Máximo Importancia Alta Urgencia Media Estado Validado Estabilidad Alta Comentarios Ninguno 65 Jorge García Flores IRQ-03 Información de opciones Versión 1.0 Autores Jorge García Flores Fuentes Objetivos asociados OBJ–01 Ejecutar emulador Master System 2 en PSP. OBJ–03 Configuración del emulador. Requisitos asociados UC–1_04 Opciones UC–1_05 Vídeo UC–1_06 Entrada UC–1_07 Rendimiento UC–1_08 Menú Descripción El sistema deberá mostrar y almacenar la información correspondiente a la configuración existente del emulador. Las opciones de configuración realmente lo son del contenedor (proceso PSP) en el que se ejecuta el emulador. Datos específicos _ Tamaño de la pantalla Ratio del manejador de la entrada Rendimiento del emulador Otras opciones de menú Tiempo de vida Medio Máximo 7 años 10 años Ocurrencias simult. Medio Máximo Importancia Alta Urgencia Media Estado Validado Estabilidad Alta Comentarios Ninguno Jorge García Flores 72 NFR– < 02 Rapidez en la ejecución del emulador Versión 1.0 Autores Jorge García Flores Fuentes Objetivos asociados OBJ–01 Ejecutar emulador Master System 2 en PSP. OBJ–02 Ejecutar juegos en el emulador. OBJ–03 Configuración del emulador. Requisitos asociados _ IRQ–01 Información de las ROMS IRQ–01_01 Información de partidas guardadas IRQ–01_02 Información del sistema IRQ–02 Información de los controles IRQ–03 Información de opciones Descripción El emulador deberá ser ejecutado lo más rápido posible para permitir un uso eficiente de él. Importancia Imprescindible Urgencia Media Estado Validado Estabilidad Alta Comentarios Ninguno NFR– < 03 Rapidez en la ejecución de las ROMS Versión 1.0 Autores Jorge García Flores Fuentes Objetivos asociados OBJ–01 Ejecutar emulador Master System 2 en PSP. OBJ–02 Ejecutar juegos en el emulador. OBJ–03 Configuración del emulador. Requisitos asociados _ IRQ–01 Información de las ROMS IRQ–01_01 Información de partidas guardadas IRQ–01_02 Información del sistema IRQ–02 Información de los controles IRQ–03 Información de opciones Descripción El emulador deberá ejecutar las ROMS lo más rápido posible y que el usuario no espere más de lo necesario. Importancia Imprescindible Urgencia Media Estado Validado Estabilidad Alta Comentarios Ninguno Como se puede ver, existe un requisito no funcional relacionado con el sistema de almacenamiento de la videoconsola PlayStation 73 Jorge García Flores Portable que es que se necesita un tamaño mínimo de la tarjeta de memoria Memory Stick. Además, la aplicación debe ser rápida a la hora de ejecutar el emulador Master System 2 y la ejecución de las ROMS para que el usuario tenga una experiencia satisfactoria con el producto. 5.3.1.- DEFINICIÓN DE ACTORES Como actor, me refiero a aquella persona susceptible de ser usuario y que interactúe con el sistema desarrollado mediante la videoconsola PlayStation Portable y pueda usar el producto. El usuario es persistente a lo largo del ciclo de duración del sistema a lo largo de todo su tiempo de vida, siendo un receptor de datos proporcionados por la salida de la aplicación, influyendo en ellos mediante la elección de una serie de diversas de opciones dadas por el sistema. Nuestro usuario no es de ningún tipo especial pues no se pide un registro ni necesitando una seguridad para que pueda acceder a ella según unos permisos establecidos, sino que es un usuario normal que puede acceder a todas las funcionalidades de la aplicación que ésta le propone y se encuentran diseñadas e implementadas. A continuación en la siguiente tabla se detalla al actor en cuestión. ACT– < 01 Usuario Versión 1.0 Autores Jorge García Flores Fuentes Descripción Este actor representa a los usuarios que ejecutan el emulador en una Playstation Portable para jugar. Comentarios Ninguno Jorge García Flores 74 5.3.2.- CASOS DE USO Un caso de uso es la descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Existen una serie de personajes que participarán en algún caso de uso y que se llaman actores. Como se ha visto anteriormente, el actor ha sido definido e identificado. Dicho esto, y con una definición que proviene de la ingeniería del software, un caso de uso es una secuencia de interacciones que se desarrollan entre un sistema y sus actores respecto a un evento que inicia un actor principal sobre el propio sistema. En el proyecto que se presenta, un usuario es el que desencadenará la ejecución de todo y que como se podrá ver a continuación en el Diagrama de Casos de Uso podrá acceder a una serie de funcionalidades cuando ocurra algún evento en particular. Así mismo, se detallan de una forma totalmente desglosada en forma de tabla como se ha visto en la asignatura de Ingeniería del Software 1. 75 Jorge García Flores UC-01 Menú_Principal Versión 1.0 Autores Jorge García Flores Fuentes Objetivos asociados OBJ–01 Ejecutar emulador Master System 2 en PSP. OBJ–02 Ejecutar juegos en el emulador. OBJ–03 Configuración del emulador. Requisitos asociados IRQ–01 Información de las ROMS IRQ–02 Información de los controles IRQ–03 Información de opciones Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario ejecute la aplicación del emulador. Precondición El emulador ha sido cargado correctamente. Secuencia normal Paso Acción 1 El usuario enciende su Playstation Portable. 2 El usuario ejecuta el emulador. 3 Carga el emulador. 4 Se accede al menú principal. Postcondición El usuario elige entre las distintas opciones del menú principal. Excepciones Paso Acción 1 Si el emulador no se ejecuta correctamente, a continuación este caso de uso queda sin efecto. Rendimiento Paso Cota de tiempo 1 5 s 2 20 ms 3 20 ms 4 5 ms Frecuencia 1 vez / ejecución Importancia Imprescindible Urgencia Alta Estado Validado Estabilidad Alta Comentarios Ninguno Jorge García Flores 76 UC-02 Cargar_ROM Versión 1.0 Autores Jorge García Flores Fuentes Objetivos asociados OBJ–01 Ejecutar emulador Master System 2 en PSP. OBJ–02 Ejecutar juegos en el emulador. Requisitos asociados IRQ–01 Información de las ROMS UC–1_03 Cargar_Guardar_Juego UC–1_10 Sistema UC–1_11 Audio UC–1_12 Vídeo2 UC–1_13 System Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario cargue una ROM en el emulador. Precondición El emulador ha sido cargado correctamente. Secuencia normal Paso Acción 1 El usuario solicita al sistema la lista de ROMs disponibles. 2 El sistema muestra las ROMs disponibles. 3 El usuario elige la ROM. 4 El emulador carga la ROM. 5 El usuario comienza la partida de dicha ROM. Postcondición El usuario comienza una partida a dicha ROM desde cero. Excepciones Paso Acción 1 Si el emulador no carga la ROM correctamente, a continuación este caso de uso queda sin efecto. Rendimiento Paso Cota de tiempo 1 5 s 2 20 ms 3 20 ms Frecuencia 1 vez / ejecución de ROM Importancia Imprescindible Urgencia Alta Estado Validado Estabilidad Alta Comentarios Ninguno 77 Jorge García Flores UC-03 Guardar_Juego Versión 1.0 Autores Jorge García Flores Fuentes Objetivos asociados OBJ–01 Ejecutar emulador Master System 2 en PSP. OBJ–02 Ejecutar juegos en el emulador. Requisitos asociados IRQ–01 Información de las ROMS IRQ–01_01 Información de partidas guardadas IRQ–01_02 Información del sistema UC–1_02 Cargar_ROM UC–1_10 Sistema UC–1_11 Audio UC–1_12 Vídeo2 UC–1_13 System Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario guarde la partida de una ROM en el emulador. Precondición El emulador y la ROM han sido cargados correctamente. Secuencia normal Paso Acción 1 El usuario solicita al sistema la lista de ROMs disponibles. 2 El sistema muestra las ROMs. 3 El usuario elige la ROM. 4 El emulador carga la ROM. 5 El usuario comienza la partida de dicha ROM. 6 El usuario carga o guarda una partida de dicha ROM. Postcondición El usuario continúa la partida de dicha ROM en el lugar que se había quedado anteriormente. Excepciones Paso Acción 1 Si el emulador no carga la ROM correctamente, a continuación este caso de uso queda sin efecto. Rendimiento Paso Cota de tiempo 1 5 s 2 20 ms 3 20 ms 4 1 s Frecuencia 1 vez / ejecución de ROM Importancia Imprescindible Urgencia Alta Estado Validado Estabilidad Alta Comentarios Ninguno Jorge García Flores 78 UC-04 Cargar_Juego Versión 1.0 Autores Jorge García Flores Fuentes Objetivos asociados OBJ–01 Ejecutar emulador Master System 2 en PSP. OBJ–02 Ejecutar juegos en el emulador. Requisitos asociados IRQ–01 Información de las ROMS IRQ–01_01 Información de partidas guardadas IRQ–01_02 Información del sistema UC–1_02 Cargar_ROM UC–1_10 Sistema UC–1_11 Audio UC–1_12 Vídeo2 UC–1_13 System Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario cargue la partida de una ROM en el emulador. Precondición El emulador y la ROM han sido cargados correctamente. Secuencia normal Paso Acción 1 El usuario solicita al sistema la lista de ROMs disponibles. 2 El sistema muestra las ROMs disponibles. 3 El usuario elige la ROM. 4 El emulador carga la ROM. 5 El usuario comienza la partida de dicha ROM. 6 El usuario carga o guarda una partida de dicha iROM. Postcondición El usuario continúa la partida de dicha ROM en el lugar que se había quedado anteriormente. En ese momento se juega a una iROM, la cual es una ROM más el estado en ejecución de la partida guardada anteriormente. Excepciones Paso Acción 1 Si el emulador no carga la ROM correctamente, a continuación este caso de uso queda sin efecto. Rendimiento Paso Cota de tiempo 1 5 s 2 20 ms 3 20 ms 4 1 s Frecuencia 1 vez / ejecución de ROM Importancia Imprescindible Urgencia Alta Estado Validado Estabilidad Alta Comentarios Ninguno 79 Jorge García Flores UC-05 Opciones del emulador Versión 1.0 Autores Jorge García Flores Fuentes Objetivos asociados OBJ–01 Ejecutar emulador Master System 2 en PSP. OBJ–03 Configuración del emulador. Requisitos asociados IRQ–03 Información de opciones UC–1_01 Menú_Principal UC–1_05 Vídeo UC–1_06 Entrada UC–1_07 Rendimiento UC–1_08 Menú Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario elige opciones del emulador (vídeo entrada, rendimiento, configurar botón de cancelar en PSP) en el menú de la interfaz del emulador. Precondición El emulador ha sido cargado correctamente. Secuencia normal Paso Acción 1 Carga el emulador. 2 El usuario elige entre las distintas opciones. 3 El sistema establece las nuevas opciones de configuración para el contenedor del emulador. Postcondición El usuario ha modificado las opciones disponibles del emulador. Excepciones Paso Acción 1 Si el emulador no carga, a continuación este caso de uso queda sin efecto. Rendimiento Paso Cota de tiempo 1 20 ms 2 10 ms Frecuencia 1 vez / ejecución Importancia Imprescindible Urgencia Alta Estado Validado Estabilidad Alta Comentarios Ninguno Jorge García Flores 80 UC-06 Vídeo Versión 1.0 Autores Jorge García Flores Fuentes Objetivos asociados OBJ–01 Ejecutar emulador Master System 2 en PSP. OBJ–03 Configuración del emulador. Requisitos asociados IRQ–03 Información de opciones UC–1_04 Opciones Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario modifica las opciones de vídeo del emulador. Precondición El emulador ha sido cargado correctamente. Secuencia normal Paso Acción 1 Carga el emulador. 2 El usuario elige la opción de Vídeo. 3 El usuario modifica la visualización del contenedor del emulador Postcondición El usuario ha modificado las opciones disponibles del emulador. Excepciones Paso Acción 1 Si el emulador no carga, a continuación este caso de uso queda sin efecto. Rendimiento Paso Cota de tiempo 1 20 ms 2 10 ms 3 5 s Frecuencia 1 vez / ejecución Importancia Imprescindible Urgencia Alta Estado Validado Estabilidad Alta Comentarios Ninguno 81 Jorge García Flores UC-07 Entrada Versión 1.0 Autores Jorge García Flores Fuentes Objetivos asociados OBJ–01 Ejecutar emulador Master System 2 en PSP. OBJ–03 Configuración del emulador. Requisitos asociados IRQ–03 Información de opciones UC–1_04 Opciones Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario modifica las opciones de entrada del emulador. Precondición El emulador ha sido cargado correctamente. Secuencia normal Paso Acción 1 Carga el emulador. 2 El usuario elige la opción de Entrada. 3 El usuario modifica la entrada del emulador Postcondición El usuario ha modificado las opciones disponibles del emulador. Excepciones Paso Acción 1 Si el emulador no carga, a continuación este caso de uso queda sin efecto. Rendimiento Paso Cota de tiempo 1 20 ms 2 10 ms 3 5 s Frecuencia 1 vez / ejecución Importancia Imprescindible Urgencia Alta Estado Validado Estabilidad Alta Comentarios Ninguno Jorge García Flores 88 UC-14 System Versión 1.0 Autores Jorge García Flores Fuentes Objetivos asociados OBJ–01 Ejecutar emulador Master System 2 en PSP. OBJ–02 Ejecutar juegos en el emulador. Requisitos asociados IRQ–01 Información de las ROMS UC–1_10 Sistema Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario modifica los parámetros de sistema una ROM, pudiendo resetear la ROM o hacer una captura de pantalla de la ROM. Precondición El emulador ha sido cargado correctamente. Secuencia normal Paso Acción 1 El usuario solicita al sistema la lista de las ROMs disponibles. 2 El sistema muestra las ROMs disponibles. 3 El usuario elige la ROM. 4 El emulador carga la ROM. 5 El usuario modifica los parámetros de sistema de la ROM. Postcondición El usuario ha modificado las opciones disponibles del emulador. Excepciones Paso Acción 1 Si el emulador o la ROM no cargan, a continuación este caso de uso queda sin efecto. Rendimiento Paso Cota de tiempo 1 5 s 2 10 ms 3 5 s Frecuencia 1 vez / ejecución Importancia Imprescindible Urgencia Alta Estado Validado Estabilidad Alta Comentarios Ninguno 89 90 Como se puede ver en el Diagrama de Casos de Uso, el actor Usuario es el que inicia todo el proceso de ejecutar la aplicación una vez que se ha encendido la videoconsola PlayStation Portable, siendo lo primero ejecutar el contenedor y una vez hecho eso, mediante relaciones extend que nos indican que son opciones que pueden realizarse o no, podremos ejecutar una ROM, cambiar la configuración de los controles o cambiar una serie de parámetros del contenedor y la propia PlayStation Portable. En el caso de que se ejecute una ROM se relaciona este caso de uso (Cargar_Rom) con otros tres casos de uso mediante relaciones extend. Estos casos de uso son Guadar_Juego, Cargar_Juego y Sistema, y a su vez el caso de uso Sistema se relaciona mediante relaciones extend con los casos de uso Audio, Vídeo2 y System. También decir que el caso de uso Opciones se relaciona de igual manera mediante relaciones extend con los casos de Vídeo, Entrada, Rendimiento y Menú. En este momento no se considera el volver a describir los casos de uso, pues ya se encuentran definidos de forma rigurosa en las tablas anteriores. 5.4.- MATRIZ DE RASTREABILIDAD La matriz de rastreabilidad se usa para poder identificar de forma rápida y concisa todos los requisitos y casos de uso asociados al proyecto y cuáles dependen unos de otros. En la siguiente tabla se puede observar de forma detallada lo explicado. OBJ-01 OBJ-02 OBJ-03 IRQ-01 • • 91 Jorge García Flores IRQ-02 • • IRQ-03 • • IRQ-01_01 • • IRQ-01_02 • • UC-01 • • • UC-02 • • UC-03 • • UC-04 • • UC-05 • • UC-06 • • UC-07 • • UC-08 • • UC-09 • • UC-10 • • UC-11 • • Jorge García Flores 92 UC-12 • • UC-13 • • UC-14 • • CRQ_01 • CRQ_02 • • NFR-01 • • • NFR-02 • • • NFR-03 • • • 5.5.- RESUMEN Este resumen es acerca de todas las tablas que se ha ido viendo a lo largo del apartado de requisitos del sistema. A continuación se muestra la tabla con el resumen de todo ello. TIPO ID Descripción OBJETIVOS OBJ–01 El sistema Sony Playstation Portable deberá ejecutar el emulador de la videoconsola Master System 2. OBJ–02 El emulador de la videoconsola Master System 2 deberá ejecutar las ROMS. OBJ–03 Se podrá configurar el emulador para características de vídeo, sonido, controles, etc. 93 Jorge García Flores REQUISITOS INFORMACION IRQ–01 El sistema deberá almacenar la información correspondiente a las ROMS, así como la carpeta en la que se encuentran. IRQ–02 El sistema deberá mostrar y almacenar la información correspondiente a las ROMS, así como la carpeta en la que se encuentran. IRQ–03 El sistema deberá mostrar y almacenar la información correspondiente a la configuración existente del emulador. IRQ–01_01 El sistema deberá mostrar y almacenar la información correspondiente a la partida guardada de una ROM. IRQ–01_02 El sistema deberá mostrar y almacenar la información correspondiente a una ROM jugada en ese momento concreto. REQUISITOS FUNCIONALES UC–1_01 El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario ejecute la aplicación del emulador. UC–1_02 El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario cargue una ROM en el emulador. UC–1_03 El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario cargue una ROM en el emulador. UC–1_04 El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario elige opciones en el menú de la interfaz del emulador. UC–1_05 El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario modifica las opciones de vídeo del emulador. UC–1_06 El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario modifica las opciones de entrada del emulador. UC–1_07 El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario modifica las opciones de rendimiento del emulador respecto a la Playstation Portable. Jorge García Flores 94 UC–1_08 El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario modifica las opciones de manejar el menú del emulador teniendo en cuenta si la Playstation Portable es japonesa o del resto del mundo, es decir, los botones X y O. UC–1_09 El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario modifica los controles cuando realiza una partida a una ROM. UC–1_10 El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario modifica los parámetros de una ROM. UC–1_11 El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario modifica los parámetros de audio una ROM. UC–1_12 El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario modifica los parámetros de vídeo una ROM, en este caso una barra vertical en la zona izquierda de la pantalla. UC–1_13 El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario modifica los parámetros de sistema una ROM, pudiendo resetear la ROM o hacer una captura de pantalla de la ROM. REQUISITOS NO FUNCIONALES NFR–01 La Memory Stick será de mínimo 32 Mb para poder guardar el emulador en ella y ser ejecutado correctamente. NFR–02 El emulador deberá ser ejecutado lo más rápido posible para permitir un uso eficiente de él. NFR–03 El emulador deberá ejecutar las ROMS lo más rápido posible y que el usuario no espere más de lo necesario. CONFLICTOS 95 Jorge García Flores 5.6.- GLOSARIO DE TÉRMINOS El glosario de términos se realiza debido a que existen una serie de términos que deben ser descritos para entender el perfecto funcionamiento del proyecto, presentándose también forma de tabla. Aunque exista redundancia y se hayan visto en el apartado de nomenclatura de términos, se ha considerado que debido a que en el DRS deben ser especificados, deban ponerse de nuevo. Nombre Descripción Master System 2 Videoconsola de tercera generación, la cual es de 8 bits, de sobremesa y es producida por SEGA. Memory Stick Tarjeta de memoria flash cuyo funcionamiento permite guardar datos, en este caso de partidas de juegos de la consola Playstation Portable, y emuladores y los propios juegos de los emuladores, además de fotos, vídeos, música, etcétera para ser ejecutados dentro de la Playstation Portable. Playstation Portable Videoconsola de séptima generación, la cual es de 32 bits, portátil y es producida por SONY. ROM Representa la memoria en la que está almacenado un juego que podrá ser ejecutado por la Master System 2. iROM Juego comenzado que se caracteriza por ser una ROM más el estado en ejecución de una partida jugada anteriormente y que ha sido guardada. Jorge García Flores 96 5.7.- ÍNDICE DE TABLAS Por último, se incluye un índice de todas las tablas que se han ido detallando a lo largo de la documentación del presente proyecto. OBJ–01 Ejecutar emulador Master System 2 en PSP. OBJ–02 Ejecutar juegos en el emulador. OBJ–03 Configuración del emulador. IRQ–01 Información de las ROMS. IRQ–01_01 Información de partidas guardadas. IRQ–01_02 Información del sistema. IRQ–02 Información de los controles. IRQ–03 Información de opciones. CRQ-01 Número máximo de partidas guardadas. CRQ-02 Cambiar opciones sin resetear emulador. RF-01 Emulador guardado en Memory Stick. RF-02 ROMS guardadas en Memory Stick. UC–1_01 Menú_Principal. UC–1_02 Cargar_ROM. UC–1_03 Cargar_Guardar_Juego. UC–1_04 Opciones. UC–1_05 Vídeo. UC–1_06 Entrada. UC–1_07 Rendimiento. UC–1_08 Menú. UC–1_09 Controles. UC–1_10 Sistema. UC–1_11 Audio. UC–1_12 Vídeo2. UC–1_13 System. 97 Jorge García Flores 6.- ANÁLISIS DEL SISTEMA El sistema simulará el comportamiento de la videoconsola Master System 2 emulada mediante software, así como se simulará la capa de virtualización de una máquina virtual mediante el contenedor que nos permitirá manejar de forma satisfactoria la aplicación. Indicar que no se va a requerir una base de datos como tal para el desarrollo del producto, si bien es necesario definir una serie de tipos abstractos de datos (TAD), sobre los que descansan la implementación del sistema y que soportan la gestión de ficheros, de imágenes, de ejecución de tareas en segundo plano, de partidas, de sonido, etc.; y que se detallan en el correspondiente apartado de la documentación técnica, relacionado con el diseño del sistema. 6.1.- DIAGRAMA DE PAQUETES Primero se va a definir qué son los paquetes, para a continuación explicar el por qué se ha utilizado este tipo de diagramas para la realización del proyecto. En UML, el paquete es un mecanismo de propósito general para organizar elementos de modelado de grupos. Los paquetes se utilizan para organizar los elementos de modelado en partes mayores que se pueden manipular como un grupo. La visibilidad de estos elementos puede controlarse para que algunos sean visibles fuera del paquete mientras que otros permanecen ocultos. Los paquetes también se pueden emplear para presentar diferentes vistas de la arquitectura del sistema [EL LENGUAJE UNIFICADO DE MODELADO –BOOCH, RUMBAUGH, JACOBSON]. Debido a esta definición se muestra claramente el por qué es necesario modelar el sistema mediante un Diagrama de Paquetes. Dicho esto, se puede observar por todo lo explicado que existen una serie de paquetes que son los que se ven en la siguiente página en la figura del Diagrama de Paquetes. Jorge García Flores 104 6.1.7.- UNIDAD PL_UTIL  Objetivo: funcionalidades que permiten guardar y cargar partidas de juegos ejecutados en la Master System 2 por medio de la videoconsola PlayStation Portable.  Descripción general: contendrá las opciones de guardar y cargar una partida de un juego ejecutado previamente y que esté ejecutándose en ese mismo instante en la Master System 2 y que se realiza mediante la librería pl_util.  Descripción técnica: los atributos y componentes del paquete pl_util de los que se harán uso en la implementación se encuentran en el archivo pl_util.h, el cual es una librería que contiene dichos métodos y atributos pero al no tener eventos ni manejadores, no es necesario definirlo mediante una tabla y con dar una relación de las operaciones se considera totalmente definidas la unidad. Nombre de la función pl_util_save_image_seq 6.1.8.- UNIDAD UI  Objetivo: funcionalidades que permiten la creación de una interfaz de usuario para el menú y poder manejar la Master System 2 por medio de la videoconsola PlayStation Portable.  Descripción general: el layout general es el que se muestra en la siguiente imagen y que será igual independientemente del lugar en el que se encuentre el usuario en el menú.  Descripción técnica: los atributos y componentes del paquete ui de los que se harán uso en la implementación se encuentran en el archivo ui.h, el cual es una librería que contiene dichos métodos y atributos que se muestran a continuación en la tabla expuesta. 105 Jorge García Flores Jorge García Flores 106 Componente pl_ui Evento Manejador PspUiFileBrowser OnRender pspUiOpenBrowser OnOk pspUiOpenBrowser OnButtonPress pspUiOpenBrowser PspUiMenu OnRender pspUiOpenMenu OnOk pspUiOpenMenu OnCancel pspUiOpenMenu OnButtonPress pspUiOpenMenu OnItemChanged pspUiOpenMenu PspUiGallery OnRender pspUiOpenGallery OnOk pspUiOpenGallery OnCancel pspUiOpenGallery OnButtonPress pspUiOpenGallery PspUiSplash OnRender pspUiSplashScreen OnCancel pspUiSplashScreen OnButtonPress pspUiSplashScreen OnGetStatusBarText pspUiSplashScreen 6.1.9.- UNIDAD PL_MENU  Objetivo: funcionalidades que permiten la creación del menú de la aplicación. 107 Jorge García Flores  Descripción general: conjunto de las diversas opciones de las que dispondrá el menú para que el usuario pueda manejar de forma correcta la aplicación.  Descripción técnica: los atributos y componentes del paquete pl_menu de los que se harán uso en la implementación se encuentran en el archivo pl_menu.h, el cual es una librería que contiene dichos métodos y atributos pero al no tener eventos ni manejadores, no es necesario definirlo mediante una tabla y con dar una relación de las operaciones se considera totalmente definidas la unidad. Jorge García Flores 108 Nombre de la función pl_menu_update_option pl_menu_remove_item pl_menu_set_item_caption pl_menu_set_item_help_text pl_menu_append_option pl_menu_find_option_by_value pl_menu_select_option_by_index pl_menu_select_option_by_value pl_menu_find_option_by_index pl_menu_create pl_menu_destroy pl_menu_clear_items pl_menu_append_item pl_menu_find_item_by_index pl_menu_remove_item pl_menu_get_item_count pl_menu_clear_options pl_menu_find_item_by_id 109 Jorge García Flores 6.1.10.- UNIDAD PL_FILE  Objetivo: funcionalidades que permiten el manejo de los directorios.  Descripción general: conjunto de las funcionalidades para poder moverse de forma totalmente eficiente a través de un sistema de directorios.  Descripción técnica: los atributos y componentes del paquete pl_file de los que se harán uso en la implementación se encuentran en el archivo pl_file.h, el cual es una librería que contiene dichos métodos y atributos pero al no tener eventos ni manejadores, no es necesario definirlo mediante una tabla y con dar una relación de las operaciones se considera totalmente definidas la unidad. Nombre de la función pl_file_get_file_list pl_file_destroy_file_list pl_file_get_file_list_count 6.1.11.- UNIDAD PL_INI  Objetivo: funcionalidades que permiten el manejo de los ficheros.  Descripción general: conjunto de las funcionalidades que permiten el correcto funcionamiento del sistema de ficheros.  Descripción técnica: los atributos y componentes del paquete pl_ini de los que se harán uso en la implementación se encuentran en el archivo pl_ini.h, el cual es una librería que contiene dichos métodos y atributos pero al no tener eventos ni manejadores, no es necesario definirlo mediante una tabla y con Jorge García Flores 110 dar una relación de las operaciones se considera totalmente definidas la unidad. Nombre de la función pl_ini_create pl_ini_destroy pl_ini_save pl_ini_get_int pl_ini_set_int pl_ini_get_string pl_ini_set_string 6.1.12.- UNIDAD PL_REWIND  Objetivo: funcionalidades que permiten el manejo de los estados de las ROMS.  Descripción general: conjunto de las funcionalidades que permiten el correcto funcionamiento de los estados de una ROM guardada.  Descripción técnica: los atributos y componentes del paquete pl_rewind de los que se harán uso en la implementación se encuentran en el archivo pl_rewind.h, el cual es una librería que contiene dichos métodos y atributos pero al no tener eventos ni manejadores, no es necesario definirlo mediante una tabla y con dar una relación de las operaciones se considera totalmente definida la unidad.  111 Jorge García Flores Nombre de la función pl_rewind_init pl_rewind_realloc pl_rewind_destroy pl_rewind_reset pl_rewind_save pl_rewind_restore 6.1.13.- UNIDAD TYPES  Objetivo: tipos definidos para poder manejar funcionalidades de otras unidades.  Descripción general: conjunto de tipos manejados por la librería psptypes.  Descripción técnica: los atributos y componentes del paquete types de los que se harán uso en la implementación se encuentran en el archivo types.h, el cual es una librería que contiene dichos atributos. Al ser una unidad que maneja librerías de la videoconsola PlayStation Portable, dichas funcionalidades se encuentran documentadas en el propio Pspsdk. 6.1.14.- UNIDAD LOADROM  Objetivo: tipos definidos para poder manejar funcionalidades para cargar y guardar estados de una ROM. Jorge García Flores 112  Descripción general: conjunto de tipos manejados por loadrom.c para permitir guardar el estado de una ROM y continuar la partida desde el mismo lugar posteriormente.  Descripción técnica: los atributos y componentes del paquete loadrom de los que se harán uso en la implementación se encuentran en el archivo loadrom.h, el cual es una librería que contiene dichos atributos. Al ser una unidad que maneja librerías de la videoconsola PlayStation Portable, dichas funcionalidades se encuentran documentadas en el propio Pspsdk. 6.1.15.- UNIDAD STATE  Objetivo: métodos para poder manejar el estado de una ROM correctamente.  Descripción general: conjunto de métodos manejados por state.c para permitir un uso adecuado del estado de una ROM cuando se guarde o cargue una partida más adelante.  Descripción técnica: los atributos y componentes del paquete state de los que se harán uso en la implementación se encuentran en el archivo state.h, el cual es una librería que contiene dichos atributos. Al ser una unidad que maneja librerías de la videoconsola PlayStation Portable, dichas funcionalidades se encuentran documentadas en el propio Pspsdk. 7.- DISEÑO DEL SISTEMA A continuación se mostrarán en este apartado una serie de pantallas a modo de ejemplo, siendo éstas un boceto que más tarde serían utilizadas para la creación del contenedor de la aplicación. Dependiendo del lugar en el que nos encontremos en el contenedor, se podrán hacer una serie de aspectos u otros y que serán detallados uno 113 Jorge García Flores por uno. Más adelante, se presentarán las mismas pantallas, pero ejecutándose bajo la videoconsola PlayStation Portable. 7.1.- DEFINICIÓN DEL TAD En el presente apartado se va a definir los TAD (tipo abstracto de datos) que se ha usado en la implementación para el Proyecto Fin de Carrera “Emulador de Master System 2 corriendo bajo PlayStation Portable” dela forma que se ve en la asignatura [ESTRUCTURA DE DATOS –PILAR GRANDE GONZÁLEZ-] Un Tipo Abstracto de Dato (TAD), es un tipo de dato en el que sólo se definen los rasgos esenciales, sin importar los detalles específicos de implementación. Son tipos de datos no primitivos en cuyo diseño se han considerado tres principios que son:  Separación.  Encapsulamiento.  Ocultación de información. Las estructuras de datos se pueden documentar como un TAD. El documentar de un TAD se realiza por medio de una especificación lógica. Además hay que considerar dos aspectos en la realización del TAD.  Externo: interfaz donde se especifican el nombre, las propiedades del tipo y las operaciones que se pueden aplicar.  Interno: implementación que comprende los algoritmos mediantes los que se realizan las operaciones. Jorge García Flores 120 PERTENENCIA DE UNIDAD NOMBRE DEL TIPO (ATRIBUTOS DEL TIPO OPERACIONES pl_rewind pl_rewind state_data_size : int state_count : int start : rewind_state current : rewind_state save_state : int load_state : int get_state_size : int pl_rewind_init pl_rewind_realloc pl_rewind_destroy pl_rewind_reset pl_rewind_save pl_rewind_restore Descripción del TAD Estructura de datos y operaciones que permite el manejo de retroceso de una partida de una ROM. OPERACIONES DEFINICIÓN pl_rewind_init Inicializar el retroceso. pl_rewind_realloc Realojar en memoria el retroceso de la partida guardada. pl_rewind_destroy Destruir el retroceso de una partida guardada anteriormente. pl_rewind_reset Resetear el retroceso de una partida guardada anteriormente. pl_rewind_save Guardar el retroceso de una partida. pl_rewind_restore Restaurar el retroceso de una partida guardada. 121 Jorge García Flores PERTENENCI A DE UNIDAD NOMBRE DEL TIPO ATRIBUTOS DEL TIPO OPERACIONES pl_snd pl_snd_stereo_samp le l : short r : short pl_snd_callback pl_snd_mono_sampl e ch : short pl_snd_init pl_snd_sample stereo : pl_snd_stereo_samp le mono : pl_snd_stereo_samp le pl_snd_set_callbac k pl_snd_pause pl_snd_resume pl_snd_shutdown Descripción del TAD Estructura de datos y operaciones que permite el manejo del sonido de la videoconsola Master System 2. OPERACIONES DEFINICIÓN pl_snd_callback Llamada en segundo plano del sonido. pl_snd_init Iniciar el sonido. pl_snd_set_callback Establecer la llamada en segundo plano del sonido. pl_snd_pause Parar el sonido momentáneamente. pl_snd_resume Restaurar el sonido que se ha parado anteriormente. pl_snd_shutdown Apagar el sonido. Jorge García Flores 122 PERTENENCIA DE UNIDAD NOMBRE DEL TIPO ATRIBUTOS DEL TIPO OPERACIONES ui PspUiMetric Background : PspImage Font : PspFont CancelButton OkButton Left : int Top : int Right : int Bottom : int ScrollbarColor ScrollbarBgColor ScrollbarWidth : int TextColor SelectedColor SelectedBgColor StatusBarColor MenuFps : int DialogFogColor BrowserFileColor BrowserDirectoryColor BrowserScreenshotDelay BrowserScreenshotPath : char[] GalleryIconsPerRow : int GalleryIconMarginWidth : int MenuItemMargin : int MenuSelOptionBg pspUiGetButtonIcon 123 Jorge García Flores MenuOptionBoxColor MenuOptionBoxBg MenuDecorColor TitlePadding : int TitleColor TabBgColor Animate : int PspUiFileBrowser Filter : char[] Userdata pspUiOpenBrowser PspUiMenu menu : pl_menu pspUiOpenGallery PspUiGallery Userdata menu : pl_menu pspUiOpenMenu PspUiSplash pspUiSplashScreen UiMetric PspUiMetric pspUiAdhocHost pspUiAdhocJoin pspUiConfirm pspUiYesNoCancel pspUiAlert pspUiFlashMessage pl_menu_item pspUiFadeout Descripción del TAD Estructura de datos y operaciones que permite el manejo de la interfaz de usuario. Jorge García Flores 124 OPERACIONES DEFINICIÓN pspUiGetButtonIcon Obtener los botones creados como iconos para la interfaz de usuario. pspUiOpenBrowser Abrir el navegador de ficheros de la interfaz de usuario. pspUiOpenGallery Abrir la galería de imágenes de la interfaz de usuario. pspUiOpenMenu Abrir el menú de la interfaz de usuario. pspUiSplashScreen Crear imagen de una ROM en la interfaz de usuario. pspUiAdhocHost Crear una partida en red en la interfaz de usuario. pspUiAdhocJoin Unirse a una partida en red por medio de la interfaz de usuario. pspUiConfirm Botón de confirmar de la interfaz de usuario. pspUiYesNoCancel Botón de cancelar de la interfaz de usuario. pspUiAlert Mensaje de alerta de la interfaz de usuario. pspUiFlashMessage Mensaje rápido de la interfaz de usuario. pl_menu_item Crear ítem del menú en la interfaz de usuario. pspUiFadeout Eliminar la interfaz de usuario. 125 Jorge García Flores PERTENENCIA DE UNIDAD NOMBRE DEL TIPO ATRIBUTOS DEL TIPO OPERACIONES video PspVertex color : int x : short y : short z : short pspVideoInit pspVideoShutdown pspVideoClearScreen pspVideoWaitVSync pspVideoSwapBuffers pspVideoBegin pspVideoEnd pspVideoPrint pspVideoPrintCenter pspVideoPrintN pspVideoPrintClipped pspVideoPrintNRaw pspVideoPrintRaw pspVideoPutImage pspVideoPutImageAlpha pspVideoGlowRect pspVideoShadowRect pspVideoGetVramBufferCopy pspVideoBeginList pspVideoCallList Jorge García Flores 126 pspVideoAllocateVramChunk pspVideoGetVSyncFreq Descripción del TAD Estructura de datos y operaciones que permite el manejo del vídeo. 127 Jorge García Flores OPERACIONES DEFINICIÓN pspVideoInit Inicializar vídeo. pspVideoShutdown Apagar vídeo. pspVideoClearScreen Limpiar la pantalla de vídeo. pspVideoWaitVSync Sincronización vertical del vídeo. pspVideoSwapBuffers Buffers de intercambio para el vídeo. pspVideoBegin Comenzar el vídeo. pspVideoEnd Finalizar el vídeo. pspVideoPrint Imprimir el video. pspVideoPrintCenter Imprimir de forma centrada el vídeo. pspVideoPrintN Imprimir N veces el vídeo. pspVideoPrintClipped Imprimir cortado el vídeo. pspVideoPrintNRaw Impirmir N filas el vídeo. pspVideoPrintRaw Imprimir una fila del vídeo. pspVideoPutImage Poner una imagen en el video. pspVideoPutImageAlpha Poner una imagen alpha en el vídeo. pspVideoGlowRect Establecer un brillo en el vídeo. pspVideoShadowRect Establecer una sombra en el vídeo. pspVideoGetVramBufferCopy Obtener una copia del buffer de la memoria de vídeo. pspVideoBeginList Comenzar la lista de vídeo. pspVideoCallList Llamar a la lista de vídeo. pspVideoAllocateVramChunk Alojar en la memoria de vídeo una parte. pspVideoGetVSyncFreq Obtener la frecuencia de vídeo mediante sincronización vertical Jorge García Flores 128 7.1.1CONSIDERACIONES ESPECIALES DE TAD En este apartado se documentan los TAD que no contienen operaciones, o tipos asociados a él, por lo que se describirán mediante sus tablas correspondientes. PERTENENCIA DE UNIDAD OPERACIONES ATRIBUTOS DEL TIPO ctrl PspCtrlInit Char[] PspCtrlGetPollingMode Int PspCtrlSetPollingMode int PspCtrlPollControls Descripción del TAD Estructura de datos y operaciones que permite la correspondencia de los controladores de la videoconsola PlayStation Portable respecto a los de la videoconsola Master System 2 que será emulada. PERTENENCIA DE UNIDAD OPERACIONES pl_util pl_util_save_image_seq pl_util_save_vram_seq pl_util_date_compare pl_util_compute_crc32_buffer pl_util_compute_crc32_fd pl_util_compute_crc32_file Descripción del TAD Estructura de datos y operaciones que permite el manejo de diversas utilidades del emulador. 129 Jorge García Flores PERTENENCIA DE UNIDAD OPERACIONES loadrom load_rom loadzip Descripción del TAD Estructura de datos y operaciones que permite la carga de una ROM. PERTENENCIA DE UNIDAD OPERACIONES state system_save_state system_load_state save_state_to_mem get_save_state_size load_state_from_mem Descripción del TAD Estructura de datos y operaciones que permite guardar o cargar el estado de una ROM ejecutada. PERTENENCIA DE UNIDAD OPERACIONES menu InitMenu DisplayMenu TrashMenu Descripción del TAD Estructura de datos y operaciones que permite guardar o cargar el estado de una ROM ejecutada. Jorge García Flores 136 7.4.- DISEÑO DE LA INTERFAZ DE USUARIO INTERFAZ: Parte muy importante de la aplicación y que se ha explicado anteriormente qué funcionalidades debe tener. De todas maneras, en este apartado se vuelve a explicar y de forma detallada las pantallas que contiene la aplicación. Hay que recordar que la interfaz es una de las partes más importantes de una aplicación, pues su buen diseño permite que una aplicación sea intuitiva, o por el contrario hace que la aplicación pueda llegar a ser un auténtico desastre y que el usuario deje de usar la aplicación. Debido a la sencillez con la que ha sido realizada y gracias a las números explicaciones que se dan en las pantallas a modo de ayuda y cambio de parámetros todos explicados, se puede decir que la interfaz se encuentra bien estructurada y facilita la navegación en la aplicación por parte del usuario, sabiendo que la máquina para la que ha sido realizada la aplicación no es una computadora y no será manejada con teclado y ratón, sino con una serie de controles más diferenciados como son cruceta, joystick analógico y una serie de botones. Por lo tanto y a modo de resumen, se puede decir que la interfaz es como sigue:  Totalmente intuitiva.  Presenta una gran accesibilidad a todo tipo de usuarios.  Gran usabilidad por la facilidad con que las personas pueden utilizar la herramienta. El producto se divide en una serie de módulos que se explicarán de una forma totalmente de tallada gracias a las pantallas que se muestran a continuación. Dichos módulos están diseñados en forma de compartimentos, los cuales son tres y que se enumeran a continuación.  Opciones del menú que se encuentran en la parte superior.  Mensajes de ayuda de la aplicación encontrándose en la parte inferior. 137 Jorge García Flores  Bloque de navegación que nos muestra diferentes características y se encuentra entre medias de los dos anteriores. Existen seis pantallas distintas, las cuales son la pantalla principal, la pantalla de los controles, la pantalla de las opciones, la pantalla con el sistema de directorios, la pantalla de cargar o guardar una ROM ejecutada previamente y la pantalla del sistema que permite las modificaciones de una ROM ejecutada previamente. En este momento se pasa a describir cada una de las pantallas de la interfaz de usuario creada para la aplicación del Proyecto Fin de Carrera: Pantalla Principal: En este boceto se puede ver la forma principal del contenedor de la aplicación para la interfaz de usuario. Se puede comprobar cómo se encuentran divididos perfectamente los tres compartimentos. En la parte superior se encuentran las tres principales opciones del menú una vez que se ha ejecutado la aplicación. Dichas opciones son Juego, Controles y Opciones (esto se irá explicando en cada pantalla). También se puede ver en la esquina superior derecha una información importante para el usuario como es la fecha y hora, el porcentaje de la Jorge García Flores 138 batería y las horas restantes que puede seguir usando la máquina PlayStation Portable sin que se conecte a la luz, es decir funcionando mediante la batería. La zona intermedia en este momento no contiene nada hasta que no se comience a navegar por el menú principal, por lo que no hay nada más que señalar en este compartimento. Por último, en la parte inferior se puede ver que es la zona de los mensajes de ayuda, y en este caso se nos indica que para navegar a través de las pestañas del menú, se usarán los botones R y L de la videoconsola PlayStation Portable. Controles: En este segundo boceto realizado, lo que se puede ver es que se sigue utilizando los mismos módulos que en la pantalla anterior, por lo que sigue la tónica general de lo que será la interfaz de usuario del contenedor. En este momento nos encontramos en el apartado de los Controles. El asterisco de la parte superior nos indica que se seguirán mostrando las mismas opciones que en la pantalla de menú principal (Juego, Controles, Opciones) y que en la parte inferior se nos indica mediante un mensaje de ayuda lo que podemos hacer. En esta pantalla, el contenedor intermedio contiene los controles que podemos utilizar para navegar por la interfaz, así como una barra de desplazamiento en la parte de la derecha para poder mostrar todo el contenido. 139 Jorge García Flores Opciones: En la tercera pantalla que se muestra mediante un boceto, se ve que es el apartado de las Opciones. Se sigue manteniendo la misma estructura que en las anteriores pantallas, por lo que no rompe con la tónica general del diseño que se desea implementar. La parte superior sigue conteniendo lo mimo que la pantalla principal, de ahí el asterisco (Juego, Controles, Opciones) y en la parte inferior se nos irá mostrando los mensajes de ayuda dependiendo de dónde nos encontremos para cambiar las opciones existentes. El módulo intermedio se encuentra los parámetros que se pueden cambiar, tanto para el emulador, como para el contenedor, así como para la propia máquina física. Jorge García Flores 140 Juego: Esta cuarta pantalla nos muestra mediante el boceto lo que será la pantalla de Juego, refiriéndose a éste como el sistema de directorios que se ha implementado para la aplicación. Sigue manteniendo la misma estructura que el resto de las pantallas. La parte superior sigue teniendo la misma información que la pantalla principal. En el módulo o compartimento inferior se muestran los mensajes de ayuda para poder movernos en la navegación de directorios. Lo más importante de esta pantalla en la interfaz de usuario es el módulo intermedio. En él no sólo veremos las ROMS almacenadas en la tarjeta de memoria Memory Stick, sino también el directorio en el que nos encontramos actualmente, por lo que ofrece una manera fácil e intuitiva de poder moverse por la interfaz para cualquier tipo de usuario. Se muestra también una barra de desplazamiento en el caso de que el usuario contenga una gran cantidad de ROMS guardadas. Otra cosa importante que se puede ver es una imagen del juego en el que se encuentra el usuario seleccionando una ROM en el caso de que haya sido guardada anteriormente. La visualización de la imagen se realiza con transparencias para permitir visualizar de forma correcta los nombres, ya que es lo que se considera más importante a la hora de navegar por el directorio. 141 Jorge García Flores Salvar/Cargar: Esta pantalla contiene una serie de consideraciones especiales que deben ser explicadas y tenidas en cuenta por parte del usuario. Lo primero que hay que indicar es que estamos en la pantalla de Salvar/Cargar un juego. Para ello, primero se debe haber ejecutado un juego (ROM) previamente y una vez hecho e ir de nuevo a la interfaz de usuario, nos aparecerán nuevas pestañas relacionadas con el juego. La primera de ellas es ésta. Aunque no rompa la estructura del contenido de la interfaz, se puede ver en la parte superior las nuevas opciones del menú en la parte superior, así como en la parte superior el mensaje de ayuda que corresponde a esta pantalla. La parte intermedia nos muestra en este momento 8 casillas distintas donde almacenar un juego guardado con su estado para ser recuperado posteriormente (al final se consiguió albergar hasta 10 partidas distintas por juego), mostrándose la casilla en la que nos encontremos con una tamaño algo mayor al resto, con una imagen del juego en el lugar en el que se encuentra guardado y la fecha y hora a la que se guardó para posteriormente reanudar su partida. Jorge García Flores 142 Sistema: La última pantalla que se presenta a modo de boceto también depende de si hemos ejecutado previamente una ROM. En este caso nos encontramos en la opción de Sistema, la cual nos permite cambiar una serie de parámetros de configuración acerca de la ROM presentado una relación de dependencia con el emulador de la Master System 2 ejecutado en ese mismo instante. Sigue la misma estructura que la pantalla de Salvar/cargar en el compartimento superior del contenedor y la misma estructura en la parte inferior que en el resto de las pantallas para el sistema de ayuda. La parte intermedia es la que nos permite cambiar los parámetros de una ROM, así como ciertos aspectos del emulador. EVENTOS: Los eventos son una serie de acciones que ocurren cuando un usuario realiza una acción. Nuestro producto contiene una serie de eventos que deben ser explicados de forma detallada para saber qué ocurre en los momentos en que un usuario realiza una acción Hay que tener en cuenta, que aunque la implementación sea una programación estructurada y no una programación orientada a eventos, sí que se debe explicar qué ocurre en el sistema. 143 Jorge García Flores En el momento de ejecutar la aplicación, el emulador de la videoconsola Master System 2 no se encuentra ejecutándose todavía. Esto es así para que no consuma recursos, además solamente el emulador se ejecutará cuando un usuario cargue una ROM (en este caso cargar una ROM sería introducir un juego de forma física en la ranura de la videoconsola física). En ese momento ocurre el evento de ejecutarse el emulador de Master System 2, el cual se encontrará corriendo bajo la videoconsola PlayStation Portable como un nuevo hilo de ejecución, por lo que en este momento ocurren dos cosas totalmente diferenciadas. La primera es que la aplicación del contenedor sigue ejecutándose, y a su vez el emulador también se ejecuta, parándose cuando un jugador cargue una nueva ROM (ya sea la misma o distinta), comenzando otra vez el proceso de emulación. Otro evento que ocurre es cuando un usuario se encuentra ya ejecutando una ROM en el emulador y desea guardar una partida o cambiar los parámetros de esa ROM o del propio contenedor, siguiendo la ejecución del emulador sin necesidad de “resetearlo” o “apagarlo”. Un nuevo evento existe cuando un usuario ha guardado una partida anteriormente de una ROM (y que llamaremos iROM a modo de imagen de una ROM) y más adelante carga una partida desde el mismo punto, habiendo ejecutado previamente la ROM original. Por otra parte, se considera también un nuevo evento cuando se permite la conexión mediante wi-fi por medio de ad-hoc a otra máquina PlayStation Portable ejecutando su propio emulador de Master System 2 (el emulador debe ser el mismo en las dos máquinas evidentemente) para poder realizar una partida a dos jugadores teniendo en cuenta que la ROM debe ser la misma, es decir el mismo juego. 8.- CUESTIONES DE IMPLEMENTACIÓN El objetivo en toda aplicación que se desarrolle es el de lograr proyectos homogéneos, ya sea en las tecnologías utilizadas para el Jorge García Flores 144 desarrollo de los proyectos como en las herramientas escogidas en la documentación generada. Se deben utilizar herramientas de desarrollo libres, de código abierto, debido a que se evita la dependencia de empresas del sector privado, así como una reducción considerable del presupuesto en los costes de desarrollo. Otra característica es que las herramientas que se deban utilizar deben ser portables siguiendo dos aspectos importantes para ello:  Ser independientes del sistema operativo utilizado.  Ser independientes de la plataforma hardware para la que se desarrollen. La aplicación ha sido desarrollada utilizando el lenguaje C/C++. Dicho lenguaje es uno de los más utilizados y de los que se encuentra más documentación. A pesar de ser un lenguaje de alto nivel, se dice que es el de más bajo nivel de los existentes por su antigüedad, por lo que para el presente proyecto ha servido, al poder utilizar también lenguaje ensamblador, además de usar las típicas instrucciones propias de un lenguaje de alto nivel como son iteraciones, estructuras de control, etc. La construcción del proyecto consta de una carpeta llamada psplib que contiene todos los ficheros implementados del contenedor que hace de capa de virtualización. Estos ficheros se relacionan con otros que se encuentran ya implementados que son el propio emulador de la videoconsola Master System 2 y ficheros implementados para la propia videoconsola PlayStation Portable y que se encuentran en el Pspsdk (el kit de desarrollo de software de la PlayStation Portable). Por lo tanto, también es necesario el uso de dicho kit de desarrollo y que se encuentra perfectamente documentado. La interfaz de usuario es muy simple, a la vez que útil y homogénea, por lo que todas las pantallas siguen la misma estructura establecida y que se ha mostrado anteriormente en el apartado [2.4.2 Diseño de la estructura de la aplicación]. Gracias a esto, se ha 145 Jorge García Flores conseguido el mayor grado de usabilidad posible que se buscaba por la sencillez que muestra. 8.1.- JUSTIFICACIÓN DE LAS TECNOLOGÍAS UTILIZADAS En este apartado se justifica el uso de todas las tecnologías que se han usado en el desarrollo del Proyecto Fin de Carrera “EMULADOR DE MASTER SYSTEM 2 CORRIENDO BAJO PLAYSTATION PORTABLE”. C/C++: El lenguaje de programación C/C++ es un lenguaje de programación de estilo clásico que permite el uso de bucles, estructuras de control, así como estructuras de datos más complejas como arrays, registros, ficheros, etc. El lenguaje C es un lenguaje de programación estructurado, mientras que C++ es su evolución a un lenguaje de programación orientado a objetos. Las características que tiene este lenguaje de programación son las siguientes:  Un núcleo del lenguaje simple, con funcionalidades añadidas importantes, como funciones matemáticas y de manejo de archivos, proporcionadas por bibliotecas.  Es un lenguaje muy flexible que permite programar con múltiples estilos. Uno de los más empleados es el estructurado "no llevado al extremo" (permitiendo ciertas licencias de ruptura).  Un sistema de tipos que impide operaciones sin sentido.  Usa un lenguaje de preprocesado, el preprocesador de C, para tareas como definir macros e incluir múltiples archivos de código fuente.