第1页 / 共70页
第2页 / 共70页
第3页 / 共70页
第4页 / 共70页
第5页 / 共70页
第6页 / 共70页
第7页 / 共70页
第8页 / 共70页
IBM DEV475 OOAD 培训课程的 UML 案例.pdf
Introduction
Definitions
Course
Course Offering
Course Catalog
Faculty
Finance System
Grade
Professor
Report Card
Roster
Student
Schedule
Transcript
Objectives
Scope
References
Functionality
Usability
Reliability
Performance
Supportability
Security
Design Constraints
Course Registration System Use-Case Model Main Diagram
Close Registration
Brief Description
Flow of Events
Basic Flow
Alternative Flows
No Professor for the Course Offering
Billing System Unavailable
Special Requirements
Pre-Conditions
Post-Conditions
Extension Points
Login
Brief Description
Flow of Events
Basic Flow
Alternative Flows
Invalid Name/Password
Special Requirements
Pre-Conditions
Post-Conditions
Extension Points
Maintain Professor Information
Brief Description
Flow of Events
Basic Flow
Add a Professor
Update a Professor
Delete a Professor
Alternative Flows
Professor Not Found
Delete Cancelled
Special Requirements
Pre-Conditions
Post-Conditions
Extension Points
Maintain Student Information
Brief Description
Flow of Events
Basic Flow
Add a Student
Update a Student
Delete a Student
Alternative Flows
Student Not Found
Delete Cancelled
Special Requirements
Pre-Conditions
Post-Conditions
Extension Points
Register for Courses
Brief Description
Flow of Events
Basic Flow
Create a Schedule
Update a Schedule
Delete a Schedule
Select Offerings
Submit Schedule
Alternative Flows
Save a Schedule
Unfulfilled Prerequisites, Course Full, or Schedule Conflicts
No Schedule Found
Course Catalog System Unavailable
Course Registration Closed
Delete Cancelled
Special Requirements
Pre-Conditions
Post-Conditions
Extension Points
Select Courses to Teach
Brief Description
Flow of Events
Basic Flow
Alternative Flows
No Course Offerings Available
Schedule Conflict
Course Catalog System Unavailable
Course Registration Closed
Special Requirements
Pre-Conditions
Post-Conditions
Extension Points
Submit Grades
Brief Description
Flow of Events
Basic Flow
Alternative Flows
No Course Offerings Taught
Special Requirements
Pre-Conditions
Post-Conditions
Extension Points
View Report Card
Brief Description
Flow of Events
Basic Flow
Alternative Flows
No Grade Information Available
Special Requirements
Pre-Conditions
Post-Conditions
Extension Points
Introduction
Definitions
Bank System
Employee
Payroll Administrator
Project Management Database
System Clock
Pay Period
Paycheck
Payment Method
Timecard
Purchase Order
Salaried Employee
Commissioned Employee
Hourly Employee
Objectives
Scope
References
Functionality
Usability
Reliability
Performance
Supportability
Security
Design Constraints
Payroll System Use-Case Model Main Diagram
Create Administrative Report
Brief Description
Flow of Events
Basic Flow
Alternative Flows
Requested Information Unavailable
Invalid Format or Insufficient Information
Special Requirements
Pre-Conditions
Post-Conditions
Extension Points
Create Employee Report
Brief Description
Flow of Events
Basic Flow
Alternative Flows
Requested Information Unavailable
Invalid Format or Insufficient Information
Special Requirements
Pre-Conditions
Post-Conditions
Extension Points
Login
Brief Description
Flow of Events
Basic Flow
Alternative Flows
Invalid Name/Password
Special Requirements
Pre-Conditions
Post-Conditions
Extension Points
Maintain Employee Information
Brief Description
Flow of Events
Basic Flow
Add an Employee
Update an Employee
Delete an Employee
Alternative Flows
Employee Not Found
Delete Cancelled
Special Requirements
Pre-Conditions
Post-Conditions
Extension Points
Maintain Purchase Order
Brief Description
Flow of Events
Basic Flow
Create a Purchase Order
Update a Purchase Order
Delete a Purchase Order
Alternative Flows
Purchase Order Not Found
Invalid Access to a Purchase Order
Purchase Order is Closed
Delete Cancelled
Special Requirements
Pre-Conditions
Post-Conditions
Extension Points
Maintain Timecard
Brief Description
Flow of Events
Basic Flow
Submit Timecard
Alternative Flows
Invalid Number of Hours
Timecard Already Submitted
Project Management Database Not Available
Special Requirements
Pre-Conditions
Post-Conditions
Extension Points
Run Payroll
Brief Description
Flow of Events
Basic Flow
Alternative Flows
Bank System Unavailable
Deleted Employees
Special Requirements
Pre-Conditions
Post-Conditions
Extension Points
Select Payment Method
Brief Description
Flow of Events
Basic Flow
Alternative Flows
Employee Not Found
Special Requirements
Pre-Conditions
Post-Conditions
Extension Points
Description
Architectural Mechanisms
Analysis Mechanisms
Analysis-to-Design-to-Implementation Mechanisms Map
Implementation Mechanisms
Security
Static View: Security
Class Descriptions
Dynamic View: Secure User Set-Up
Dynamic View: Secure Data Access
Persistency - RDBMS - JDBC
Static View: Persistency JDBC
Class Descriptions
Dynamic View: JDBC RDBMS Read
Dynamic View: JDBC RDBMS Update
Dynamic View: JDBC RDBMS Create
Dynamic View: JDBC RDBMS Delete
Dynamic View: JDBC RDBMS Initialize
Persistency - OODBMS - ObjectStore
Static View: Persistency – ObjectStore OODBMS
Class Descriptions
Static View: Persistency - DBManager Detail
Class Descriptions
Dynamic View: ObjectStore – OODBMS Create
Dynamic View: ObjectStore OODBMS Delete
Dynamic View: ObjectStore OODBMS Read
Dynamic View: ObjectStore OODBMS Update
Dynamic View: ObjectStore OODBMS Initialize
Dynamic View: ObjectStore OODBMS Shutdown
Distribution - RMI
Static View: Distribution - RMI
Class Descriptions
Dynamic View: Set Up Remote Connection (details)
Dynamic View: Set Up Remote Connection
Logical View
Architectural Analysis
Upper-Level Layers
Upper-Level Layer Dependencies
Architectural Design
Incorporating ObjectStore
Architectural Layers and Their Dependencies: Main Diagram
Layer Descriptions
Packages and Their Dependencies: Package Dependencies Diagram
Package Descriptions
Process View
Processes
Design Element to Process Mapping
Deployment View
Nodes and Connections
Process-to-Node Map
IBM Rational Software
Section 1: Course Registration Requirements
Version 2004
Section 1: Course Registration Requirements
Problem Statement
As the head of information systems for Wylie 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.
Copyright IBM Corp. 2004
Page 2
Section 1: Course Registration Requirements
Glossary
Introduction
This document is used to define terminology specific to the problem domain, explaining terms, which may
be unfamiliar to the reader of the use-case descriptions or other project documents. Often, this document
can be used as an informal data dictionary, capturing data definitions so that use-case descriptions and
other project documents can focus on what the system must do with the information.
Definitions
The glossary contains the working definitions for the key concepts in the Course Registration System.
Course
A class offered by the university.
Course Offering
A specific delivery of the course for a specific semester – you could run the same course in parallel
sessions in the semester. Includes the days of the week and times it is offered.
Course Catalog
The unabridged catalog of all courses offered by the university.
Faculty
All the professors teaching at the university.
Finance System
The system used for processing billing information.
Grade
The evaluation of a particular student for a particular course offering.
Professor
A person teaching classes at the university.
Report Card
All the grades for all courses taken by a student in a given semester.
Roster
All the students enrolled in a particular course offering.
Student
A person enrolled in classes at the university.
Schedule
The courses a student has selected for the current semester.
Transcript
The history of the grades for all courses, for a particular student sent to the finance system, which in turn
bills the students.
Copyright IBM Corp. 2004
Page 3
Section 1: Course Registration Requirements
Supplementary Specification
Objectives
The purpose of this document is to define requirements of the Course Registration System. This
Supplementary Specification lists the requirements that are not readily captured in the use cases of the use-
case model. The Supplementary Specifications and the use-case model together capture a complete set of
requirements on the system.
Scope
This Supplementary Specification applies to the Course Registration System, which will be developed by
the OOAD students.
This specification defines the non-functional requirements of the system; such as reliability, usability,
performance, and supportability, as well as functional requirements that are common across a number of
use cases. (The functional requirements are defined in the Use Case Specifications.)
References
None.
Functionality
Multiple users must be able to perform their work concurrently.
If a course offering becomes full while a student is building a schedule including that offering, the student
must be notified.
Usability
The desktop user-interface shall be Windows 95/98 compliant.
Reliability
The system shall be available 24 hours a day 7 days a week, with no more than 10% down time.
Performance
The system shall support up to 2000 simultaneous users against the central database at any given time, and
up to 500 simultaneous users against the local servers at any one time.
The system shall provide access to the legacy course catalog database with no more than a 10 second
latency.
Note: Risk-based prototypes have found that the legacy course catalog database cannot meet our
performance needs without some creative use of mid-tier processing power
The system must be able to complete 80% of all transactions within 2 minutes.
Supportability
None.
Security
The system must prevent students from changing any schedules other than their own, and professors from
modifying assigned course offerings for other professors.
Only Professors can enter grades for students.
Only the Registrar is allowed to change any student information.
Copyright IBM Corp. 2004
Page 4
Section 1: Course Registration Requirements
Design Constraints
The system shall integrate with an existing legacy system, the Course Catalog System, which is an RDBMS
database.
The system shall provide a Windows-based desktop interface.
Copyright IBM Corp. 2004
Page 5
Section 1: Course Registration Requirements
Course Registration System Use-Case Model Main Diagram
Use-Case Model
Student
Professor
View Report Card
Register for Courses
Login
Course Catalog
Select Courses to Teach
Submit Grades
Registrar
Maintain Professor Information
Maintain Student Information
Close Registration
Billing System
Copyright IBM Corp. 2004
Page 6
Section 1: Course Registration Requirements
Close Registration
Brief Description
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.
Flow of Events
Basic Flow
This use case starts when the Registrar requests that the system close registration.
1. The system checks to see if registration is in progress. If it is, then a message is displayed to the Registrar, and
the use case terminates. The Close Registration processing cannot be performed if registration is in progress.
2. For each course offering, the system checks if a professor has signed up to teach the course offering and at least
three students have registered. If so, the system commits the course offering for each schedule that contains it.
3. For each schedule, the system “levels” the schedule: if the schedule does not have the maximum number of
primary courses selected, the system attempts to select alternates from the schedule’s list of alternates. The first
available alternate course offerings will be selected. If no alternates are available, then no substitution will be
made.
4. For each course offering, the system closes all course offerings. If the course offerings do not have at least
three students at this point (some may have been added as a result of leveling), then the system cancels the
course offering. The system cancels the course offering for each schedule that contains it.
5. The system calculates the tuition owed by each student for his current semester schedule and sends a transaction
to the Billing System. The Billing System will send the bill to the students, which will include a copy of their
final schedule.
Alternative Flows
No Professor for the Course Offering
If, in the Basic Flow, there is no professor signed up to teach the course offering, the system will cancel the
course offering. The system cancels the course offering for each schedule that contains it.
Billing System Unavailable
If the system is unable to communicate with the Billing System, the system will attempt to re-send the
request after a specified period. The system will continue to attempt to re-send until the Billing System
becomes available.
Special Requirements
None.
Pre-Conditions
The Registrar must be logged onto the system in order for this use case to begin.
Post-Conditions
If the use case was successful, registration is now closed. If not, the system state remains unchanged.
Extension Points
None.
Copyright IBM Corp. 2004
Page 7
Section 1: Course Registration Requirements
Login
Brief Description
This use case describes how a user logs into the Course Registration System.
Flow of Events
Basic Flow
This use case starts when the actor wishes to log into the Course Registration System.
1. The actor enters his/her name and password.
2. The system validates the entered name and password and logs the actor into the system.
Alternative Flows
Invalid Name/Password
If, in the Basic Flow, the actor enters an invalid name and/or password, the system displays an error
message. The actor can choose to either return to the beginning of the Basic Flow or cancel the login, at
which point the use case ends.
Special Requirements
None.
Pre-Conditions
The system is in the login state and has the login screen displayed.
Post-Conditions
If the use case was successful, the actor is now logged into the system. If not, the system state is unchanged.
Extension Points
None.
Copyright IBM Corp. 2004
Page 8
相关推荐
2023年江西萍乡中考道德与法治真题及答案.doc
2012年重庆南川中考生物真题及答案.doc
2013年江西师范大学地理学综合及文艺理论基础考研真题.doc
2020年四川甘孜小升初语文真题及答案I卷.doc
2020年注册岩土工程师专业基础考试真题及答案.doc
2023-2024学年福建省厦门市九年级上学期数学月考试题及答案.doc
2021-2022学年辽宁省沈阳市大东区九年级上学期语文期末试题及答案.doc
2022-2023学年北京东城区初三第一学期物理期末试卷及答案.doc
2018上半年江西教师资格初中地理学科知识与教学能力真题及答案.doc
2012年河北国家公务员申论考试真题及答案-省级.doc
2020-2021学年江苏省扬州市江都区邵樊片九年级上学期数学第一次质量检测试题及答案.doc
2022下半年黑龙江教师资格证中学综合素质真题及答案.doc
