www.developer.com/design/article.php/2109801
By Mandar Chitnis, Pravin Tiwari, & Lakshmi Ananthamurthy March 14, 2003 Dos and Don'tsUse cases should not be used to capture all the details of a system. The granularity to which you define use cases in a diagram should be enough to keep the use case diagram uncluttered and readable, yet, be complete without missing significant aspects of the required functionality. You will encounter such decision points of the level of granularity that you need to define when you build any of the UML diagrams. An important rule that gets forgotten during use creation is the creeping in of design issues. Use cases are meant to capture "what" the system is, not "how" the system will be designed or built. Use cases should be free of any design characteristics. If you end up defining design characteristics in a use case, you need to go back to the drawing board and start again. Case study—Courseware Management SystemUse case modeling, as we have learnt today, involves analyzing the problem statement to determine the business processes of the system. We will now design the use case model for the Courseware Management System case study. Note: In case you need to revisit the problem statement of the Courseware Management System described in Article 2, click here. Let us analyze the problem statement to identify the potential actors and use cases of the system. First, let us list the potential actors. A quick look at the problem statement shows up the following terms and entities specific to the system:
Identifying Actors of the Courseware Management SystemOut of the preceding list, one thing is clear. There are certain terms and entities in the list that identify that they perform certain roles or business processes. We will discuss what these business processes are after we complete our analysis for identifying actors. For now, we focus on identifying the actors in the system. From the preceding list, we can see that there are some entities that perform an action and some that form the target for the action. The entities that perform action will be the actors for the Courseware Management System. In the above list, the actors that we can identify are:
But, because students are not the potential active participants for this system, we will drop them from the list of actors. Similarly, tutors are not active participants from our system's perspective, and hence, we will exclude tutors from our list if roles. Yet, we will still record them in our use case model since we do not wish to lose this business information. Our final list of primary actors has now come down to only one:
Identifying Use Cases of the Courseware Management SystemNext, let us identify the potential business processes in the Courseware Management System. The primary business flows in the system are:
As we analyze the problem statement further, we can determine some discrete processes within these primary business flows. To manage courses, the actor needs to have the ability to view existing courses, manage the course information for a course, such as duration and so forth, and also manage the addition or removal of topics for a course. So, within the "Manage courses" use case, we can identify the following sub processes:
And similarly, the "Manage course assignment" use case can be refined into smaller discrete processes such as viewing the course calendar, viewing tutors, managing the tutor information of tutors working for the organization, and of course, assigning courses to tutors. Now, the use cases that we have identified within the "Manage course assignment" use case are:
Our final list of use cases for the courseware management system will now be:
Use Case Diagram
Figure 3.8: the use case diagram for the Courseware Management System We have completed identifying potential use cases and actors. Take a look at the use case diagram for the Courseware Management System in Figure 3.7. The use case diagram of the Courseware Management System includes all the actors and use cases that we identified during our analysis of the problem statement. SummaryUse case diagrams were the starting point of our journey in exploring each of the UML diagrams. Business functionality can be quickly represented in a simple and lucid fashion by using use case diagrams. Once the groundwork for depicting use cases is completed, the next step, as we learnt today, is writing detailed use case scenarios that will be used as the base functional requirements for the system. Our exercise in defining the use case diagram for the Courseware Management System case study was useful and enabled us to get a hands-on experience in applying what we learnt today. In the coming article, we will study the next UML diagram—the Class diagram. About the AuthorsMandar S. Chitnis, Lakshmi Ananthamurthy, and Pravin S. Tiwari are the co-founders of Novusware, Inc. They have co-authored the book Teach Yourself BEA WebLogic Server 7.0 in 21 Days (SAMS publishing Oct 2002) based on the recently launched WebLogic Server 7.0 by BEA Systems inc. For any questions or queries regarding the article contents, please contact articlewriters@novusware.com. # # # |
| Go to page: Prev 1 2 3 4 |
Jupitermedia Corporation has two divisions: Jupiterimages and JupiterOnlineMedia
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Tech Jobs | Shopping | E-mail Offers
