Subtitles of the Movie

La organizacion de los componentes que vamos a utilizar en la aplicacion "Where's Tom" es muy sencilla. Si visualizamos la aplicacion "Where's Tom" como un grupo de objetos relacionados que cooperan entre si, como vimos en la frase de la definicion de la programacion orientada a objetos, podemos ver algunos de los modulos mas obvios, como por ejemplo el modulo "Users" o el modulo "Activities". Luego, para cada uno de los modulos podemos determinar las unidades funcionales y la manera en la cual estas cooperan entre si. Esto nos ayudara a determinar la estructura de las clases de los componentes. En cuanto a las unidades funcionales, buscamos una funcionalidad que tenga un punto de entrada, un objetivo y un punto de salida clarificados. Para la mayoria de estos componentes, estas funciones van a corresponder a la busqueda, la visualizacion, la insercion y la edicion de los datos. Un ejercicio interesante que tenemos al planificar las unidades funcionales consiste en intentar imaginar la manera en la cual cada una de estas es utilizada por otras. Por ejemplo, podriamos imaginar la manera en la cual el objeto "Users" trabaja de manera cooperativa con el objeto "Locations". He creado un diagrama de la posible cooperacion entre las unidades funcionales de la aplicacion "Where's Tom". El objeto "Users" coopera con el objeto "Activities" al buscar las actividades realizadas por un usuario en particular. El metodo "searchUsers", sin ningun criterio, provee una lista de los posibles usuarios que realizan estas actividades. El objeto "Locations" coopera con el objeto "Activities" de una manera similar. Cuando queremos buscar las actividades realizadas en una ubicacion en particular, el metodo "searchLocation", sin ningun criterio, nos brinda toda una lista de las ubicaciones que podemos utilizar en la busqueda. Los metodos "searchUsers" y "searchLocations" tambien se utilizan para las actividades de insercion y actualizacion de los datos. Cuando buscamos, insertamos o editamos un usuario, no necesitamos ninguna otra funcionalidad proveniente de otro modulo. y lo mismo ocurre con las ubicaciones, pues estos elementos proveen una funcionalidad pero no necesitan ninguna por si mismos. El modulo "Activities" trabaja en conjunto con el modulo "Supplies" porque una actividad requiere de unos suministros. Este aspecto al menos nos da una idea de la manera como interactuan los objetos funcionales. Ahora veamos la estructura de los componentes. Hemos creado este mapa de componentes anteriormente al planear el proceso de la aplicacion. y vamos a verlo de nuevo para confirmar las decisiones que hemos tomado. Tenemos una distribucion muy sencilla de la funcionalidad con unas caracteristicas a lo largo de los conjuntos de funcionalidad. Hemos indicado unas propiedades en este diagrama y conservaremos este aspecto aqui para describir las caracteristicas de cada uno de los modulos funcionales, aunque no utilizamos la etiqueta "properties" en los componentes. Necesitamos el modulo "Supplies" aunque vamos a utilizar un servicio web para buscar los suministros. en vez de almacenar la informacion en la base de datos. Sin embargo tenemos que modificar los metodos, pues necesitamos un metodo "searchSupplies" para buscar los suministros y un metodo "addToBriefcase" para agregarlos al maletin de Tom. Tambien necesitamos un metodo "displayBriefcase" para desplegar el maletin. Asi mismo, tambien debemos agregar algunas propiedades. Estos nombres han cambiado, asi que debemos ingresar los nuevos nombres. Vamos a agregar el campo "ActivitySupplyID", el cual utilizaremos para realizar un seguimiento de esta informacion. Recuerde que en la configuracion de las tablas definimos los campos "ActivityID", "ItemName", "ItemNumber", "ItemDescription", "ItemImage" y el campo "AddedOn" que nos permite conocer el tiempo en el cual se agrego el suministro al registro que estamos conservando. El resto del diagrama luce bien, asi que estamos listos para continuar. rama luce bien, asi que estamos listos para continuar.