Assignment 3: UML Sequence And Class Diagram Exercise 1 ✓ Solved
Assignment 3: UML Sequence and Class Diagram(s) Exercise 1
Assignment 3: UML Sequence and Class Diagram(s)
Exercise 1 (4 Points) As the head of information systems for a college you are tasked with developing a new student registration system. The system will allow students to register for courses and view report cards. Professors will access the system to sign up to teach courses and record grades. The new system will access the existing course catalog database (Ingres on DEC VAX) via an open SQL interface from Unix servers, but will not update it. Course offerings have a max of 10 and min of 3 students; offerings with fewer than 3 are canceled. Students can add/drop during the add/drop period. After registration, information is sent to the Billing System. If a course fills up, notify the student before submitting. At semester end students view electronic report cards. The system must secure grades. Professors can view signups and record grades.
The Use Case Model and Descriptions outline the following use cases: 1) Login: actors Student, Professor, Registrar; 2) Register for Courses: student registers for current semester, can modify/delete during add/drop; Billing System notified; 3) View Report Card: student views previous semester; 4) Close Registration: Registrar closes the registration, underfilled offerings canceled; Billing System notified for non-cancelled offerings; 5) Maintain Professor Information: Registrar add/modify/delete professors; 6) Maintain Student Information: Registrar add/modify/delete students; 7) Select Courses to Teach: Professor selects course offerings from catalog for upcoming semester; 8) Submit Grades: Professor submits grades for classes.
In addition, the scenario includes the students requesting course catalog lists, the registrar maintaining data about people, and interactions with the Billing System. The design requires a sequence of interactions among actors (Student, Professor, Registrar) and software components (Course Catalog System, Billing System, Course Catalog Database, etc.), and a class model that captures students, professors, registrar staff, courses, offerings, enrollments, and billing records. This exercise emphasizes modeling the dynamic behavior (sequence diagrams) and the structural view (class diagrams) to support a scalable, secure, and maintainable registration ecosystem.
Scope note: The goal is to produce sequence and class diagrams for the described Use Cases, focusing on the critical interactions, information exchange, and responsibilities of primary actors and supporting systems. Security constraints, data integrity rules, and notification flows should be reflected in the models where appropriate.
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.” Your task is to draw the sequence diagram for the “Buy Item” use case and also draw the class diagram.
The Buy Item use case involves a Customer (primary actor) and a Point-of-Sale system with supporting entities such as Inventory, Receipt, Payment, and Clerk. The main flow includes the customer selecting items, the clerk recording the purchase, the POS system recording the sale, and the customer leaving with a receipt. Extensions include real-time credit card verification. The solution should identify core domain classes (Item, Inventory, Sale/Transaction, Payment, Receipt, Clerk) and their attributes and operations, and show how they collaborate in the sequence to complete a sale. Emphasize the clear separation of concerns between inventory management, sales processing, and payment handling for maintainability and potential future extension (e.g., loyalty programs, multiple payment methods, or vendor management).
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 (customer account information), Exchanges (NYSE, NASDAQ, Pacific Stock Exchange), SecurityTable (information about tradable securities). Prerequisite: User is an authorized customer, has logged into the stock trading system and 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; trade can be Market or Limit; 2) System looks up the stock, verifies valid symbol, checks exchange for latest price; 3) If Limit, user provides constraints: date range and price range; 4) System checks Brokerage DB for authorization: for sale, user must own sufficient shares; for purchase, credit limit must be sufficient (Market uses current price; Limit uses max price); 5) User is shown a statement and confirms or cancels; 6) If Market, system places order via exchange; 7) If Limit, system schedules daily checks beginning at the start date until traded or end date, querying the exchange hourly and issuing orders when price constraints are met; 8) System returns user to the starting panel; 9) When traded, a transaction statement is issued and emailed, 10) DB updated to reflect new holdings and cash balance. Alternate scenarios cover invalid symbol, insufficient credit or stock, cancellation after end date, or timeout of confirmation.
Tasks: 1) Specify the classes to implement this design, aligned with real-world objects plus software entities needed to perform the activities; 2) Develop interaction diagrams for the main success scenario and any alternate scenarios; 3) Create a class diagram with operations and attributes as needed; 4) Propose an extensible design to accommodate future extensions: a) Differences between exchanges (multiple protocols) should be encapsulated via subclassing; b) Addition of new securities beyond stocks (bonds, funds, options) via inheritance; c) Addition of new kinds of trades (e.g., exercise for options) via inheritance to support extensibility.
Paper For Above Instructions
Introduction
This paper presents a structured approach to modeling the three exercises using UML Sequence and Class Diagrams. The focus is on capturing core responsibilities, data flows, and collaboration patterns while enabling a scalable, maintainable design. The analysis uses standard OO design principles and established modeling guidance from foundational texts in the field (Sommerville, 2011; Booch et al., 1999; Larman, 2004). In addition, use-case driven design and abstracted interfaces are emphasized to support extensibility as required in Exercise 3 (Jacobson et al., 1992; Cockburn, 2001).
Exercise 1: College Course Registration System
Sequence diagram concepts
Key interactions involve a student, professor, or registrar issuing use-case driven requests to supporting subsystems: Course Catalog System, Registration Engine, Billing System, and a secure data store for course information. A typical login sequence authenticates a user against a security service; registration involves selecting four primary course offerings plus two alternates, with add/drop window checks and enforcement of a minimum enrollment threshold (three students). If a course fills, the system notifies the student prior to final submission. On successful registration, a billing event is generated and sent to the Billing System. At semester end, students can view electronic report cards with restricted access to protect grades.
An illustrative textual sequence for “Register for Courses” follows: Student asserts intent to register; Registration Engine queries the Course Catalog for offerings; the system validates the four primary and two alternate selections against availability; if a course offering is full at the moment of submission, a real-time alert prevents finalization; once accepted, Registration Engine updates Enrollment records and triggers a Billing System event; any changes during add/drop period propagate to Billing; after processing, a confirmation is returned to the Student. This sequence can be captured in a UML Sequence Diagram with lifelines for Student, RegistrationUI, RegistrationEngine, CourseCatalog, BillingSystem, and CourseOffering.
Class diagram concepts
Core classes include Student, Professor, Registrar, Course, CourseOffering, Enrollment, CourseCatalog, BillingRecord, and SecurityPolicy. Associations capture that Students enroll in CourseOfferings (Enrollment as a junction), Professors teach CourseOfferings, and CourseCatalog contains CourseOfferings with attributes such as term, capacity, and prerequisites. Important attributes include courseCode, title, department, professorId, capacity, enrolledCount, and prerequisites; operations include addEnrollment(courseOffering, student), cancelOffering(courseOffering) and billStudent(billingRecord). Security considerations call for a UserAccount entity and AccessControl policies to ensure only authorized users can view grades and modify enrollments.
Rationale: A well-structured class diagram isolates enrollment logic, course management, and billing concerns, enabling separation of concerns and easier changes to course catalog data sources (e.g., migrating from legacy databases) while enforcing minimum enrollment rules and add/drop windows (Sommerville, 2011; Larman, 2004).
Exercise 2: Buy Item Use Case in a Grocery POS
Sequence diagram concepts
The Buy Item flow includes the Customer, Clerk, POS System, Inventory, Payment Processor, and Receipt Printer. The sequence begins with item selection, followed by the clerk initiating the sale, the POS recording the transaction, payment authorization (cash or real-time credit card validation), inventory decrement, and receipt issuance. In case of credit card payments, real-time validation and risk checks are applied before finalizing the sale. If the customer requests a receipt, the POS prints it after payment confirmation.
Textual sequence outline: Customer selects items -> Clerk scans items -> POS creates SaleTransaction -> PaymentProcessor authorizes payment (cash/credit) -> Inventory.decrement(items) -> POS prints receipt -> Customer leaves. This sequence captures cross-cutting concerns such as inventory integrity and payment validation in real time.
Class diagram concepts
Proposed domain classes include Item, Inventory, Sale (or Transaction), Payment, Receipt, Clerk, Customer, and Vendor. Key attributes: Item.itemCode, Item.price, Inventory.quantity, Sale.totalAmount, Payment.type (cash/credit), Payment.status, Receipt.content. Core operations: Inventory.checkStock(itemCode), Inventory.decrement(itemCode, qty), Sale.addItem(item, qty), Payment.process(amount, paymentMethod), Receipt.generate(sale). The design supports extension to loyalty programs, multiple store locations, and different payment providers, aligning with OO design principles for cohesion and loose coupling (Cockburn, 2001; Ambler, 2002).
Exercise 3: Stock Trading System
Class model and extensibility
The stock trading domain includes User, BrokerageDB, Exchange (abstract), NYSEExchange, NASDAQExchange, PSEExchange, SecurityTable, TradeOrder, MarketData, Portfolio, and CashBalance. A robust design uses an abstract Exchange class with concrete subclasses per exchange to encapsulate protocol differences for price retrieval and order execution. SecurityTable provides stock symbol validity and metadata. BrokerageDB stores user credentials, holdings, credit lines, and permissions. The TradeOrder aggregates symbol, shares, direction (buy/sell), order type (Market/Limit), and constraints (limit price, time window). The Portfolio maintains holdings and cash balance; MarketData supplies real-time quotes. Prerequisite states that the User is authenticated and presented with a starting panel to specify a trade.
Extensible design: (a) Exchanges as subclasses encapsulate exchange-specific price and order formats; (b) Securities hierarchy allows adding bonds, funds, and options; (c) Trades can evolve with new derivatives by introducing an abstract Trade and concrete subclasses (e.g., BuyMarketShare, SellLimitShare). The main success flow includes verifying symbol validity, checking user authorization and balance, presenting a trade summary for confirmation, submitting Market trades immediately or scheduling Limit trades with periodic price checks, and updating holdings and cash after execution. Alternate paths cover invalid inputs, insufficient funds or shares, cancellation, or timeouts (Sommerville, 2011; Jacobson et al., 1992).
Interaction and class diagram considerations
One or more interaction diagrams should illustrate the main success scenario and alternate paths. A class diagram should show associations between User, BrokerageDB, Portfolio, Exchange, MarketData, SecurityTable, and TradeOrder, with clear operations such as authorizeUser(user), getLatestPrice(symbol), validateSymbol(symbol), placeOrder(exchange, tradeOrder), and updateHoldings(tradeOrder). The design emphasizes reuse, extensibility, and maintainability (Larman, 2004; Kruchten, 2003).
References