Reproductor de música en Actionscript 3, usando POO y patrón MVC

Fases de análisis y diseño

Para la fase de análisis lo ideal es hacer uso, valga la redundancia, de los casos de uso. Los casos de uso son junto con los diagramas UML una forma esquemática y con gran nivel de abstracción de hacer una aproximación a lo que queremos conseguir. Si no sabes lo que significan ambos términos, puedes consultar en estos enlaces:

http://www.ingenierosoftware.com/analisisydiseno/casosdeuso.php

http://www.clikear.com/manuales/uml/diagramascasouso.aspx

De una forma resumida, un caso de uso debería describir cómo es usada la aplicación por parte del usuario. Las interacciones entre usuario-aplicación. Voy a poner algunos casos de uso para mi reproductor MP3:

  • Hacer clic en botón Play
  • Hacer clic en botón Stop
  • Hacer clic en zona de arrastre
  • Soltar zona de arrastre
  • Fin de una canción
  • Pasa un segundo en la reprodución de una canción
  • ….

Una vez tengamos más o menos los casos de uso de la aplicación, se ha de describir cada uno de ellos para una serie de factores: actor principal del caso de uso, requisitos previos, escenario de éxito principal, escenarios alternativos (p.ej errores), requisitos especiales, etc. A continuación, la descripción detallada del caso de uso “hacer clic en botón Pause”:

Hacer clic en botón Pause

Actor principal: Usuario

Precondiciones: La reproducción ha de estar en marcha, y por lo tanto, el botón Pause visible en el lugar del botón de Play

Escenario de éxito principal:

  • Se detiene la canción elegida en el tiempo actual
  • Se vuelve a colocar el botón Play en lugar de Pause desde la biblioteca.
  • Reasignar funcionalidad al botón de Play.

Escenarios alternativos, requisitos especiales o puntos abiertos: no hay

A partir de los casos de uso y los diagramas UML, se puede tener una idea de lo que pueden ser las clases candidatas. Las clases candidatas son potencialmente las clases de la aplicación. Dentro del análisis y el diseño se pueden descartar unas que no tengan suficientes responsabilidades, y pueden surgir otras. Cada clase candidata ha de tener asignadas una serie de responsabilidades. Y si para cualquier responsabilidad asignada, una clase candidata no puede llevarla a cabo por sí sola, sino con ayuda de otra clase candidata, esta última se convierte en un colaborador. Es conveniente reunir una serie de cuartillas de papel, llamadas comunmente tarjetas CRC, donde anotar cada clase candidata, sus responsabilidades, y una reseña con las clases candidatas colaboradoras, que también tendrán su respectiva tarjeta CRC. Tras cumplimentarlas por separado, se pueden extender sobre una mesa de trabajo de una forma que dé a entender las interrelaciones entre ellas. Es una buena forma de estudiarlas. Si se quiere seguir un patrón MVC, hay que intentar separar lo que son las clases que se ocupen de la parte de los datos, las que lleven el control principal, y las que se ocupen de mostrar los gráficos y la interfaz gráfica de usuario.

A continuación expongo de forma esquemática algunas de esas clases candidatas, con sus responsabilidades y colaboradores:

Lista Almacén de Canciones

Responsabilidades

  • Recibir datos leídos externamente
  • Procesar dichos datos para almacenarlos de una forma adecuada, en una lista o array.
  • Cada item de dicha lista ha de contener una clase candidata llamada Almacén Canción
  • La lista ha de estar disponible para cualquier clase que la solicite.

Colaboradores

  • Almacén de Canción

Lista Visual de Canciones

Responsabilidades:

  • Recibir los datos de la Lista Almacén
  • Mostrar los datos visuales (artista y título de canción) a modo de listado
  • Permitir la selección de items del listado con teclado o clic de ratón.
  • Permitir el doble clic.

Colaboradores:

  • Controlador

Controlador

Responsabilidades:

  • Obtener datos externos
  • Crear Vista Reproductor
  • Una vez obtenidos datos externos, crear Lista Almacén
  • A partir de la Lista Almacén, llenar la Lista Visual
  • Asignar control de eventos de clic en los botones
  • Intercambiar botones donde proceda (p.ej play-pause) cuando se haga clic

Colaboradores:

  • Lista Almacén de Canciones
  • Almacén de Canción
  • Vista Reproductor

Una vez finalizado el análisis y diseño y obtenidas las que serán finalmente las clases, habrá que concretar también sus responsabilidades en forma de métodos. Una responsabilidad puede ser cumplimentada por uno o varios métodos.

A continuación es hora de pasar a la parte de la implementación.sd

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>