Design Specifications


Let’s turn straight to the task of learning the requirements for the Project Tracker application. As discussed in Chapter 1, before you ever write a single line of code you should carefully plan your application on paper. Start this design process by determining exactly what the new application needs to do, who will use it, and what they are currently using. Go on a fact-finding mission to determine what needs the new application must meet. Many applications fail because coding was done too early and it was hard to retrofit changes. You may recall the house building analogy: If you wait until the first two floors have been framed to tell your builder you want a basement, you incur a lot of expense to get it at that point. The same concept applies in the world of programming. The more you plan up front, the better off you will be.

In the present case study, you have already talked to users and determined that each person needs a way to track his own personal projects. Corporate systems are in place to manage contacts, billing, and even projects for the company. However, the users are complaining that they need a simpler way to track their own little tasks in a coherent way. This system is not meant to replace the existing systems. The users will still have to maintain the projects in the master system. However, the personal details for each user’s daily work do not need to be maintained in the master system, nor does management want them to be.

With that in mind, you determine that the application should, at least, allow users to track simple details about their projects, as well as store related contact information for each project. The user interface format should allow the user to navigate through the records one at a time. Preferably, only open projects should be displayed on the screen when the application opens, but the users must also have some way to see all projects, including those that are closed.

The Use Case Diagram, shown in Figure 13-1, illustrates these basic requirements.

image from book
Figure 13-1

Eight use cases are shown in Figure 13-1. Users can open the Project Tracker application with only unclosed records displayed (U.C. 1.1) but have the option to see all project records (U.C. 1.2). Buttons allow navigation among the records (U.C. 1.3). In addition, the application enables users to update existing (U.C. 1.4), add new (U.C. 1.5), and delete existing (U.C. 1.6) records. From the Project Tracker screen, a user can open the Contacts screen to see contact details for a particular contact that is associated with the project (U.C. 1.7). A user can also open the Contacts screen and manage existing contacts (U.C. 1.8) and add/associate a particular contact with the current project.

From the Contacts screen, you determine that the user should be able to view and manage contacts in a manner similar to the way the Project Tracker screen does, with record navigation and update capabilities. In addition, the user needs an option to associate a selected contact with the currently open project. Figure 13-2 shows these features represented in a Use Case Diagram.

image from book
Figure 13-2

Again, the user can open contacts records (U.C. 2.1), and update (U.C. 2.2), add new (U.C. 2.3), and delete (U.C. 2.4) contact records. Record navigation is provided (U.C. 2.5) to enable viewing and maintenance of contacts. Furthermore, a user can associate a contact record with the currently open project on the project form (U.C. 2.6).

You may determine that although it is not required, it would also be desirable to add enhanced features, such as the capability to create a new e-mail to send to a selected contact from the project record. Users also want to associate external files, such as related documents and spreadsheets, with a project record. You might decide to include these features in the application because they will add a lot of additional value to the users, and management has approved of this approach.

As discussed in Chapter 1, you have various other ways to document the application, including activity diagrams, other flow charts, network diagrams, object diagrams, and so on. Exactly what you do is not so important, as long as you arrive at a coherent design on paper before you begin writing the application. In Access, I typically generate prototype screens by using Access forms, because the work of drawing the forms can be reused when you actually start coding the forms. I sometimes use Visio to generate prototype screens as well. In any event, when you analyze the requirements previously discussed, you might determine that two main screens make sense: a Project Tracker screen and a Contacts screen. The Project Tracker screen can be further divided into tabs, such as a first tab for Comments/Tasks, a second tab for related contacts, and a third tab for file attachments. This design is illustrated in Figures 13-3, 13-4, and 13-5.

image from book
Figure 13-3

image from book
Figure 13-4

image from book
Figure 13-5

Figure 13-3 shows the general information for the project as well as the Comments tab where the user can enter tasks or comments about the project. The user can enter a comment or task in the Comment/Task Text field and then click the Add Comment button to add it to the project. Because you are planning to implement a disconnected recordset scenario as described in detail in Chapter 5 on ADO, you will not actually be saving the changes to the underlying database until the user clicks the Save Changes button. The Delete Comment button removes the comment from the list on the form but does not remove the comment from the database until the Save Changes button is later clicked.

Figure 13-4 shows the same general project information at the top portion of the screen and has a Contacts tab where related contact records can be managed. Notice the button with the mail icon on the right of the contact list. You intend for a button such as this to enable a user to generate an e-mail to the currently selected contact in the list. This tab is where users launch the Contacts screen to view more information about the selected contact, manage existing contacts, and associate them with the current contact. The Delete Selected Contact button simply removes the contact from this project but not from the database until Save Changes is clicked.

Figure 13-5 includes a File Attachments tab where users can associate separate files with the current project. The Preview button to the right of the list will allow a user to open a selected file attachment in a separate window in its native application. A File Open button allows a user to search on the file system for an attachment and includes any selected file name in the File Name field to be added to the project. After the user fills in a file description and file name and selects the Add File Attachment button, the file is added to the list.

Figure 13-6 is a prototype screen for Contacts. Notice how various data elements related to the contact are included, as well as navigation buttons and buttons for saving changes to records. The Add Current Contact To Project button allows a user to put the current contact back on the project form for the currently open project. Now that you have a written plan detailing what you want the application to do, it’s time to get your hands dirty creating the database and the code!

image from book
Figure 13-6




Beginning Access 2007 VBA
Beginning Access 2007 VBA
ISBN: 0470046848
EAN: 2147483647
Year: 2004
Pages: 143

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net