Subtitles of the Movie

In our "Where's Tom" application, organizing the components we'll be using is fairly straight forward. If we view the "Where's Tom" application as a cooperative group of related objects, recognize that phrase from the definition of object oriented programming? We can see right away some of the more obvious modules, for example, users or activities. Then for each of these modules we can determine functional units and how the units will cooperate with each other. This will help us determine the structure of our component classes. For functional units we are looking for functionality that has a clear entry point, a clear goal and a clear exit point. For most of the components these functions would be actions like search, view, insert and edit. An interesting exercise when plotting out the functional units is to try to imagine how each unit would be used by another unit. For example, how would the users object work cooperatively with the locations object. I've created a diagram of the possible cooperation between the functional units in the "Where's Tom" application. Users cooperates with activities when we want to search activities by a particular user. The search user method without any criteria provides a list of possible users with these activities. Locations cooperates with activities in a similar way. When we want to search activities at a particular location, the search location method, without any criteria, gives us a whole list of locations to use in the search. Search users and search locations are also used for inserting and updating activities. When we search or insert or edit a user, we don't really need any other functionality from any other module. The same is true for locations. It provides functionality but doesn't need any itself. The activities module works closely with the supplies module since that activity is what requires supplying. This at least begins to give us an idea of how our functional objects will interact. Now we can look at the structure of our components. We created this component map early in the planning process of our application. Returning to it now we can confirm our earlier decisions. We do have a very simple distribution of functionality with unique characteristics across the sets of functionality. We've indicated properties on this diagram and will leave these here to describe the characteristics of each functional module, even though we won't actually use the properties tag in the components. We do need a supplies module, even though we'll be using a web service to lookup supplies, rather than storing information in the data\base. We need to change the methods however, we need a search supplies method and an add to briefcase method. We also need a display briefcase method. We also need to add a couple of properties. These names have changed. So we'll just put the new names in. We'll add activity supply id, which is the field we'll be using to track this information. If you remember that from setting up the tables, activity id, item name, item number, item description, item image and added on which is a date field and let's us know when the supply was actually added to our record keeping. The rest still looks pretty good, so we're good to go. let's us know when the supply was actually added to our record keeping. The rest still looks pretty good, so we're good to go.