| Getting Started With Your New Application Project When you're getting ready to create an application, it's tempting to go straight to the coding phase. But if you don't think through an initial design approach, you could be stuck with a complete system redesign and a maintenance nightmare as soon as that first change request comes in. Before you begin coding, take a look at a simple application and think it through. The application to be developed is a typical To-do list manager. The initial set of requirements are a stand-alone application that supports the entry of tasks with different priorities and due dates. The application must also be able to print a report of outstanding tasks. This may not sound very complicated, but it is easy to imagine a user wanting support for more features: - A web interface. Instead of a stand-alone application, the user needs a web interface.
- Support for multiple users. Each user can have his or her own list of tasks.
- Ability to create reports. The user's boss wants a weekly report of the list of completed tasks.
None of these added features is that complicated on its own. But how you design the original system will have serious implications for how you will add each of the features. For instance, when a task is completed, if the application deletes the task from the system, there is no way to generate a report of completed tasks at a later time. You can argue that just about everything in the original system can be extended. How much future-proofing do you need to do? This decision is primarily driven by available time and resources. Although disk space is relatively inexpensive, if the application is targeted to a mobile phone, saving all completed tasks might make less sense. Moving from the theoretical to the To-do list manager, where do you start with the design? To go from design to code, it is helpful to document the usage scenarios, or use cases. For something as simple as the To-do list manager, this step might seem like overkill, but in the grand scheme of things, it helps you to understand what tasks are expected to be supported within an application. Once applications get bigger, you'll find that creating use cases help when you work with project stakeholders, who tend to think about the tasks they need to do. Creating the use cases involves going through the requirements and documenting the tasks that need to be done. For the original requirements of the To-do list manager, the easy set of requirements are the following: - Create a task.
- Mark the task as completed.
- View the current To-do list.
- Generate the report.
The original requirements include prioritizing tasks and ensuring that tasks have a due date, but those are really parts of creating a task. Common sense says that there should be an "update task" requirement, but that is not explicitly spelled out in the requirements. If this were a real-life project, you would need to go back to the domain expert and ask whether updating tasks is a requirement. They would probably say, "Duh, isn't that obvious?" However, it is always safest to ask to make sure you always fully understand the requirements for the system. Thus, there is one more requirement to add: Depending upon implementation, marking a task as completed can be done during the edit task use case. However, marking tasks as completed or edited still involves separate use cases. When everything is completed, successful implementation of the use cases involves testing both cases. Once you feel you have all the use cases, you can start coding. However, as projects get bigger, it is helpful to formalize the use cases in documentation with additional details. Although you might write each use case on an index card, you typically combine them all into a use case diagram for system documentation. A use case diagram offers an overview of the system design involving actors, the tasks they perform (the use cases), and their relationships. Figure 1 shows what a use case diagram might look like for the To-do list manager: 
Each use case is named with an action verb. Nowhere is there mention of how the list of tasks is displayed. For example, is a tree or table view used? Unless the display format is a hard requirement, it should not be part of a use case. With the simple version of the To-do list manager, there is only one actor in the system, the user. Had this been designed for multiple users, the left side of the diagram might show User 1, User 2, User 3, and so on as actors. And another actor called Boss could be there as the receiver of the weekly status report. Each of these actors is external to the system and only interacts with the system. One person could be different actors in the system if that person has different roles at different times. For instance, when the boss wants to manage the To-do list, the boss becomes User N, not Boss, as far as the use case diagram is concerned. Once the use case diagram is complete, you can jump into coding. As you go from diagram to coding, each use case presents a high-level interface that can be used by the system. Because you'll need to support each of the use cases, the high-level coding structure requires methods of the same name. Then connect the tasks with some user interface element. If you design it well, changing the user interface from a stand-alone application to something like a web interface should be easy, as the business logic should be sufficiently separated out to not be dependent on the user interface. Getting this right takes practice. Working with use case diagrams should help in getting you in the right direction. For additional information on use cases, the Wikipedia entry http://en.wikipedia.org/wiki/Use_case includes benefits, limitations, and guidelines for writing. There are also many helpful books out on the topic and online tutorials. | 
