Example of use case diagram for student registration system

Software Engineering (Fall '20) BSCS-F-17 Department of Computer Science Air University Assignment 3: UML Sequence and Class Diagram(s) (10 Points)

Exercise 1 (4 Points) As the head of information systems for a college 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 federal 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 Ingres relational database running on a DEC VAX. Fortunately the college 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 ensure 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’s office will continue to maintain course information through another 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 canceled. 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 on-line 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. Give below are the UML Use Case Diagram and Use Case Specifications (Descriptions). Your task is to draw the Sequence and Class Diagram(s).

Use Case Model

Use Case Descriptions 1. Login: This use case describes how a user logs into the Course Registration System. The actors

starting this use case are Student, Professor, and Registrar. 2. Register for Courses: This use case allows a student to register for courses in the current semester.

The student can also modify or delete course selections if changes are made within the add/drop period at the beginning of the semester. The Billing System is notified of all registration updates. The Course Catalog provides a list of all the course offerings for the current semester. The main actor of this use case is the student. The Course Catalog System is an actor within the use case.

3. View Report Card: This use case allows a student to view his/her report card for the previously completed semester. The student is the actor of this use case.

4. Close Registration: This use case allows a Registrar to close the registration process. Course offerings that do not have enough students are cancelled. Course offerings must have a minimum of three students in them. The billing system is notified for each student in each course offering that is not cancelled, so the student can be billed for the course offering. The main actor of this use case is the Registrar. The Billing System is an actor involved within this use case.

5. Maintain Professor Information: This use case allows the registrar to maintain professor information in the registration system. This includes adding, modifying, and deleting professors from the system. The actor of this use case is the Registrar.

6. Maintain Student Information: This use case allows the registrar to maintain student information in the registration system. This includes adding, modifying, and deleting students from the system. The actor for this use case is the Registrar.

7. Select Courses to Teach: This use case allows a professor to select the course offerings (date- and time- specific courses will be given) from the course catalog for the courses that he/she is eligible for and wishes to teach in the upcoming semester. The actor starting this use case is the Professor. The Course Catalog System is an actor within the use case.

8. Submit Grades: This use case allows a professor to submit student grades for one or more classes completed in the previous semester. The actor in this use case is the Professor.

Exercise 2 (2 Points) Pa and Ma have a grocery store downtown. The store sells all types of grocery items. Pa and Ma heard that you are currently taking a class involving Object-Oriented Analysis and Design and solicited your assistance to help develop a Point-of-Sales system for the store. Some of the expected capabilities of the system include the ability to capture sales for each item sold, be able to accept cash payments or credit

card payments, be able to track total sales by transaction or by time period, be able to track an item’s inventory level, be able to print a receipt, be able to list/print the inventory level for a specific item, and be able to track vendors/suppliers. Give below are the UML Use Case Diagram and Use Case Specification of “Buy Item”. UML Model

Use Case Description Use Case Name: Buy Item Relevant requirements: none Primary Actor: Customer Pre-conditions: - Customer has at least an item to purchase - Customer has cash or credit payment for the sale transaction Post-conditions: - Sale amount and sold item is recorded in the system - Inventory of sold item is updated - Clerk collects cash or credit card payment - Customer receives goods purchased and receipt of transaction Basic Flow or Main Scenario: 1. A customer arrives at a checkout counter with items to purchase 2. The store clerk records the purchase and collects payment 3. The POS system records sale transaction 4. The customer leaves with the bought goods and receipt upon completion Extensions or Alternate Flows: none Exceptions: Credit Card Payment verification and validation must be real-time Your task is to draw the sequence diagram for the “Buy Item” use case and also draw the class diagram.

Exercise 3 (4 Points) In this problem you will learn object-oriented analysis and design guidelines. You are asked to design a system that performs stock trades (buy or sell) for customers of a stock brokerage house. Your classes should support the following use case: Actors:

• User (customer of brokerage house who is buying or selling stock)

• Brokerage DB: This is the database of customer account information. Can tell what stocks a customer holds, how large is the customer credit line, and other information that is associated with the customer account.

• Exchanges: These include the New York Stock Exchange, NASDAQ, and the Pacific Stock Exchange. These can determine current stock prices, can execute buy or sell orders at current market price

• SecurityTable: This is a database that provides information about all securities (stocks, options, funds, etc.) that can be traded. It can identify the stock symbol, company name, name of exchange on which it is traded, etc.

Prerequisite: User is an authorized customer, has logged into the stock trading system. User is shown the starting panel for specifying a stock trade. Main Success scenario: 1. User specifies proposed trade: company(stock symbol), number of shares, buy or sell. The

proposed trade is either a "Market" trade, i.e., an order to trade at the current price, or a "Limit" trade, a trade that is limited by constraints.

2. System looks up the stock, verifies that it's a valid symbol and checks the appropriate exchange to find the latest price.

3. If the user specifies a "Limit" trade, user is required to provide the constraints: A date range (start and end), and a price range (minimum, maximum).

4. System checks the Brokerage DB to make sure the user is authorized to submit the trade: a. If it's a sale, the user must own sufficient shares of the stock to be traded b. If it's a purchase, the user's credit limit must be sufficient to cover the proposed purchase,

namely i. On a Market purchase, the credit must be sufficient for the number of shares at the current

market price of the stock ii. On a Limit purchase, the credit must be sufficient for the number of shares at the maximum

price specified. 5. The user is presented a statement of the proposed trade, and is asked to confirm or cancel. 6. If it's a market trade, the system orders the trade to proceed, using the exchange. 7. If it's a limit trade, the system schedules the following every trading day beginning at start date,

until the stock is traded or the end date is reached: a. Once every hour the Exchange is queried to determine the current stock price. If the current

stock price is between the minimum price and the maximum price, an order is issued, to proceed to trade the stock at the current market value.

8. The system then returns the user to the application starting panel. 9. When the stock is traded, a statement is issued for the transaction, indicating the total stock trade

value plus or minus any additional charges. The statement is sent via e-mail to the customer. 10. When the stock is traded, the DB is updated, changing the customer's stock holdings and cash

balance to reflect the purchase.

Alternate scenarios:

• In step 1, if the company or other info is not valid, user is requested to resubmit information.

• In step 4, if user does not have sufficient credit (on a purchase): An error message is issued, return to starting panel.

• In step 4, if user does not have sufficient stock (on a sale): An error message is issued, return to starting panel.

• In step 7, if the stock has not traded by the ending date, the trade is cancelled.

• In step 5, if the user does not confirm within 1 hour of logging in, the user is returned to the log-in panel.

1. Specify the classes to implement this design. These should be associated with real-world objects in the use case, plus additional software entities needed to perform the activities in the use case.

2. Develop one or more interaction diagrams for this use case. There should be one interaction diagram for the main success scenario, and there may be additional interaction diagrams if the alternate scenarios require changes to the diagram that are not obvious.

3. Create a class diagram with operations and attributes as needed in the interaction diagram. 4. Now consider ways of improving the object oriented design. To support reuse and be maintainable,

your design should be extensible under anticipated extensions of the system. Your design should be prepared for the following extensions: a. Differences between exchanges: Your application will have to interface with several exchanges.

(NY stock exchange, NASDAQ, and the Pacific exchange, and more may be added later). Each exchange has a different protocol for obtaining prices and executing trades. A good object- oriented design will encapsulate the differences between these protocols in subclasses, so that other classes do not need to know details about differences between exchanges.

b. Addition of new securities: The original requirement is only to support stock purchases and sales. But you can reasonably expect that there will someday be a need to support the trading of other securities, like bonds, mutual funds, and options. Use inheritance to make your design extensible in this way.

c. Addition of new kinds of trades: Currently your design must support "buy" and "sell" trades. Sooner or later other trades may be required, for example a holder of options may need an "exercise" trade. Make sure your use of inheritance supports such extensions.