Part 1 – Identifying Use Cases – Use Case Diagrams
Recently I went through OOAD and UML training. The OOAD and UML tutorial was very impressive and I decided to share it with you. Object Oriented Analysis & Design and Unified Modelling Language is very important in a life cycle of a project. Previously I was involved in project requirement study and technical design. But this time, I learned the tricks of the trade. I discovered different tips for identifying Use Cases, Actors and Classes. In this series of posts, I am planning to take you through the process of involvement of UML in Requirement analysis and Design phase.
This series will include 3 parts...
Part 1. Identifying Use Cases – Use Case Diagrams
Part 2. Realizing Use Cases – Sequence Diagrams
Part 3. Identifying Classes – Class Diagrams
For this purpose we will take commonly available sample requirement – Student Registration process. From this requirement we will identify the ACTORS and USE CASES.
Tip: For identifying Actors, identify Noun in the requirement provided to you. Also identify external systems as actors.
Tip: For identifying Use Cases, identify Verb in the requirement provided.
________________________________________________________
Sample Student Registration Requirement
As the head of information systems for WestCoast University you are tasked with developing a new student registration system. The college would like a new client-server system to replace its much older system developed around mainframe technology. The new system will allow students to register for courses and view report cards from personal computers attached to the campus LAN. Professors will be able to access the system to sign up to teach courses as well as record grades.
Due to a decrease in government funding the college cannot afford to replace the entire system at once. The college will keep the existing course catalog database where all course information is maintained. This database is an Ingress relational database running on a DEC VAX. Fortunately the university has invested in an open SQL interface that allows access to this database from college's Unix servers. The legacy system performance is rather poor, so the new system must insure that access to the data on the legacy system occurs in a timely manner. The new system will access course information from the legacy database but will not update it. The registrar maintains course information, professor information and student information through the same system.
At the beginning of each semester students may request a course catalogue containing a list of course offerings for the semester. Information about each course, such as professor, department, and prerequisites will be included to help students make informed decisions.
The new system will allow students to select four course offerings for the coming semester. In addition, each student will indicate two alternative choices in case the student cannot be assigned to a primary selection. Course offerings will have a maximum of ten students and a minimum of three students. A course offering with fewer than three students will be cancelled. For each semester, there is a period of time that students can change their schedule. Students must be able to access the system during this time to add or drop courses. Once the registration process is completed for a student, the registration system sends information to the billing system so the student can be billed for the semester. If a course fills up during the actual registration process, the student must be notified of the change before submitting the schedule for processing.
At the end of the semester, the student will be able to access the system to view an electronic report card. Since student grades are sensitive information, the system must employ extra security measures to prevent unauthorized access.
Professors must be able to access the online system to indicate which courses they will be teaching. They will also need to see which students signed up for their course offerings; In addition, the professors will be able to record the grades for the students in each class.
___________________________________________________________
From the above requirement, we have identified 6 Actors:
1.Student
2.Professor
3.Registrar
4.Legacy System / Course Catalog (External system)
5.Billing System (External system)
6.New DB (External system)
And there are 13 use cases:
1.Registration
2.Notification
3.Registration for Secondary Courses
4.Modify Schedule
5.View Report Card
6.Authentication
7.Sign up to Teach
8.Record Grades
9.View Student Details
10.Maintain Student Details
11.Maintain Professor Details
12.Maintain Course Details
13.Cancellation of Courses
Now we will see how these Actors and Use Cases are depicted in Use Case diagram. I have made use of Enterprise Architect for tooling.
- Vighnesh Bendre
Recently I went through OOAD and UML training. The OOAD and UML tutorial was very impressive and I decided to share it with you. Object Oriented Analysis & Design and Unified Modelling Language is very important in a life cycle of a project. Previously I was involved in project requirement study and technical design. But this time, I learned the tricks of the trade. I discovered different tips for identifying Use Cases, Actors and Classes. In this series of posts, I am planning to take you through the process of involvement of UML in Requirement analysis and Design phase.
This series will include 3 parts...
Part 1. Identifying Use Cases – Use Case Diagrams
Part 2. Realizing Use Cases – Sequence Diagrams
Part 3. Identifying Classes – Class Diagrams
For this purpose we will take commonly available sample requirement – Student Registration process. From this requirement we will identify the ACTORS and USE CASES.
Tip: For identifying Actors, identify Noun in the requirement provided to you. Also identify external systems as actors.
Tip: For identifying Use Cases, identify Verb in the requirement provided.
________________________________________________________
Sample Student Registration Requirement
As the head of information systems for WestCoast University you are tasked with developing a new student registration system. The college would like a new client-server system to replace its much older system developed around mainframe technology. The new system will allow students to register for courses and view report cards from personal computers attached to the campus LAN. Professors will be able to access the system to sign up to teach courses as well as record grades.
Due to a decrease in government funding the college cannot afford to replace the entire system at once. The college will keep the existing course catalog database where all course information is maintained. This database is an Ingress relational database running on a DEC VAX. Fortunately the university has invested in an open SQL interface that allows access to this database from college's Unix servers. The legacy system performance is rather poor, so the new system must insure that access to the data on the legacy system occurs in a timely manner. The new system will access course information from the legacy database but will not update it. The registrar maintains course information, professor information and student information through the same system.
At the beginning of each semester students may request a course catalogue containing a list of course offerings for the semester. Information about each course, such as professor, department, and prerequisites will be included to help students make informed decisions.
The new system will allow students to select four course offerings for the coming semester. In addition, each student will indicate two alternative choices in case the student cannot be assigned to a primary selection. Course offerings will have a maximum of ten students and a minimum of three students. A course offering with fewer than three students will be cancelled. For each semester, there is a period of time that students can change their schedule. Students must be able to access the system during this time to add or drop courses. Once the registration process is completed for a student, the registration system sends information to the billing system so the student can be billed for the semester. If a course fills up during the actual registration process, the student must be notified of the change before submitting the schedule for processing.
At the end of the semester, the student will be able to access the system to view an electronic report card. Since student grades are sensitive information, the system must employ extra security measures to prevent unauthorized access.
Professors must be able to access the online system to indicate which courses they will be teaching. They will also need to see which students signed up for their course offerings; In addition, the professors will be able to record the grades for the students in each class.
___________________________________________________________
From the above requirement, we have identified 6 Actors:
1.Student
2.Professor
3.Registrar
4.Legacy System / Course Catalog (External system)
5.Billing System (External system)
6.New DB (External system)
And there are 13 use cases:
1.Registration
2.Notification
3.Registration for Secondary Courses
4.Modify Schedule
5.View Report Card
6.Authentication
7.Sign up to Teach
8.Record Grades
9.View Student Details
10.Maintain Student Details
11.Maintain Professor Details
12.Maintain Course Details
13.Cancellation of Courses
Now we will see how these Actors and Use Cases are depicted in Use Case diagram. I have made use of Enterprise Architect for tooling.
Professor System.
Registrar System.
In the next part, I am going to talk about Realizing Use Cases – Sequence Diagrams.
- Vighnesh Bendre
Comments