October 22, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Creating Use Case Diagrams

  • March 14, 2003
  • By Mandar Chitnis, Pravin Tiwari, & Lakshmi Ananthamurthy
  • Send Email »
  • More Articles »

Dos and Don'ts with UML Use Cases

UML use 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.

UML Case study—Courseware Management System

Use case modeling, as you 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.

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:

  • Courses and Topics that make up a course
  • Tutors who teach courses
  • Course administrators who mange the assignment of the courses to tutors
  • Calendar or Course Schedule is generated as a result of the
  • Students who refer to the Course schedule or Calendar to decide which courses they wish to take up for study

Identifying Actors of the Courseware Management System

Out 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, focus on identifying the actors in the system. From the preceding list, you 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:

  • Tutors
  • Course administrators
  • Students

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:

  • Course administrators

Identifying Use Cases of the Courseware Management System

Next, let us identify the potential business processes in the Courseware Management System. The primary business flows in the system are:

  • Manage courses
  • Manage course assignments

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:

  • View courses
  • Manage topics for a course
  • Manage course information

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:

  • View course calendar
  • View tutors
  • Manage tutor information
  • Assign courses to tutors

Our final list of use cases for the courseware management system will now be:

  • View courses
  • Manage topics for a course
  • Manage course information
  • View course calendar
  • View tutors
  • Manage tutor information
  • Assign courses to tutors
If you were analyzing a sentence in English, the subject in the sentence can be identified as a potential actor and the verb part of the sentence can be a potential use case. Remember, this may or may not apply to the problem at hand, but is a good starting point for use case modeling.

Use Case Diagram



Click here for a larger image.

Figure 3.8: the UML use case diagram for the Courseware Management System

You 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.

Summary

Use 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, you will study the next UML diagram—the Class diagram.

About the Authors

Mandar 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.

# # #





Page 4 of 4



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel