UML建模实例课程注册系统.docx
- 文档编号:7848830
- 上传时间:2023-01-26
- 格式:DOCX
- 页数:18
- 大小:94.77KB
UML建模实例课程注册系统.docx
《UML建模实例课程注册系统.docx》由会员分享,可在线阅读,更多相关《UML建模实例课程注册系统.docx(18页珍藏版)》请在冰豆网上搜索。
UML建模实例课程注册系统
课程注册系统
软件构架文档
版本1.0
修订历史记录
日期
版本
说明
作者
21/March/1999
1.0
使用SoDA模板和Rose模型生成软件构架文档。
S.Johnson
1.简要说明
2.参考
3.构架表示方式
4.构架目标和约束
5.用例视图
6.逻辑视图
7.进程视图
8.部署视图
9.大小和性能
10.质量
软件构架文档
1.简要说明
软件构架文档提供了课程注册系统构架方面的综合概述。
课程注册系统是WylieCollege为支持联机课程注册而进行开发的。
本文档从利用Rose实施的课程注册分析设计模型中直接生成。
大部分章节都是使用SoDA和软件构架文档模板从Rose模型中摘录而来。
2.参考
适用的参考资料包括:
1.课程收费接口规约,WC93332,1985,WylieCollegePress。
2.课程目录数据库规约,WC93422,1985,WylieCollegePress。
3.课程注册系统前景文档,WyIT387,1.0版,1998,WylieCollegeIT。
4.课程注册系统词汇表,WyIT406,2.0版本,1999,WylieCollegeIT。
5.用例规约-结束注册,WyIT403,2.0版,1999,WylieCollegeIT。
6.用例规约-登录,WyIT401,2.0版,1999,WylieCollegeIT。
7.用例规约-维护教授信息,WyIT407,2.0版,1999,WylieCollegeIT。
8.用例规约-课程注册,WyIT402,2.0版,1999,WylieCollegeIT。
9.用例规约-选择要开授的课程,WyIT405,2.0版,1999,WylieCollegeIT。
10.用例规约-维护学生信息,WyIT408,2.0版,1999,WylieCollegeIT。
11.用例规约-提交分数,WyIT409,2.0版,1999,WylieCollegeIT。
12.用例规约-查看报告卡,WyIT410,2.0版,1999,WylieCollegeIT。
13.课程注册系统的项目计划,WyIT418,1.0版,1999,WylieCollegeIT。
14.E1迭代计划,WyIT420,1.0版,1999,WylieCollegeIT。
15.补充规约,WyIT400,1.0版,1999,WylieCollege,IT。
1.构架表示方式
本文档以一系列的视图表示构架,包括用例视图、流程视图、部署视图和实施视图。
这些视图表示为RoseModel并使用统一建模语言(UML)。
2.构架目标和约束
有一些重要的需求和系统约束对构架有重大的影响。
它们分别是:
1.必须访问WylieCollege现有遗留的课程目录系统以检索本学期所有课程的信息。
课程注册系统必须支持遗留课程目录系统[2]采用的数据格式和DBMS。
2.必须与WylieCollege现有遗留的财务系统交互以支持对学生的收费工作。
该接口在课程收费接口规约[1]中已有定义。
3.无论是本地校园网的PC还是拨号上网的远程PC,所有的学生、教授和注册员都必须能够在这些PC上执行他们各自对应的功能。
4.课程注册系统必须确保对数据进行完全保护使它们不接受XX的访问。
所有的远程访问都必须受用户确认和密码控制的约束。
5.课程注册系统以客户机服务器系统的形式进行实施。
客户端位于PC上而服务器端必须在WylieCollegeUNIX服务器上运行。
[3]
6.在开发构架时,必须考虑前景文档[3]和补充规约[15]中规定的所有性能和负载需求。
1.用例视图
关于软件构架用例视图的说明。
对于所选择的场景集和(或)作为迭代焦点的用例集,用例视图是很重要的输入。
用例视图描述那些代表了某些重要的核心功能的场景集和/或用例集。
它还要描述那些在构架方面的涉及范围很广(使用了许多构架元素)的场景集和/或用例集,或者那些强调或阐明了构架的某一具体的细微之处的场景集和/或用例集。
课程注册用例包括:
-登录(Login)
-课程注册(RegisterforCourses)
-维护学生信息(MaintainStudentInformation)
-维护教授信息(MaintainProfessorInformation)
-选择要讲授的课程(SelectCoursestoTeach)
-提交成绩(SubmitGrades)
-查看成绩报告单(ViewReportCard)
-结束注册(CloseRegistration)
这些用例由学生、教授或者注册员主角启动执行。
此外,还与外部主角交互;同时还有课程目录和收费系统。
1.在构架方面具有重要意义的用例
图名:
在构架方面具有重要意义的用例
1.结束注册
简要说明:
本用例允许注册员结束注册流程。
开设的课程如果没有足够学生则将被取消。
每门开设课程必须至少有三名学生。
每门没有被取消的课程按各个学生的情况通知收费系统,这样就可以根据该门课程对学生进行收费。
本用例主要的主角是注册员。
收费系统是本用例中包含的一个主角。
2.登录
简要说明:
本用例描述了用户如何登录到课程注册系统。
启用此用例的主角为学生、教授和注册员。
3.维护教授信息
简要说明:
本用例允许注册员维护注册系统中的教授信息。
其中包括添加、修改和从系统中删除教授信息。
本用例的主角是注册员。
4.选择要讲授的课程
简要说明:
本用例允许教授从课程目录里选择他(她)在新学期适合任教而且也愿意讲授的课程(课程的时间和日期将在以后安排)。
教授是开始本用例的主角。
课程目录系统是用例中包含的一个主角。
5.课程注册
简要说明:
本用例允许学生注册本学期的课程。
如果在学期开始的选/退课期间情况发生一些变化,那么学生也可以修改或删除自己所选的课程。
所有的注册更新都会通知给收费系统。
课程目录提供一个本学期所有课程的列表。
本用例主要的主要主角是学生。
课程目录系统是用例中包含的一个主角。
6.查看成绩报告单
简要说明:
本用例允许学生查看他(她)在上一个结束学期的成绩报告单。
本用例的主角是学生。
7.提交成绩
简要说明:
本用例允许教授提交在上个学期结束授课的一个或多个班的学生成绩。
本用例的主角是教授。
8.维护学生信息
简要说明:
本用例允许注册员维护注册系统中的学生信息。
其中包括添加、修改和从系统中删除学生信息。
本用例的主角是注册员。
2.逻辑视图
关于构架的逻辑视图的说明。
该视图说明了最为重要的类、它们在服务包和子系统中的组织以及如何将子系统组织为多个层。
还说明了最重要的用例实现(例如,构架的动态方面)。
类图还可以用来说明在构架方面具有主要意义的类、子系统、包和层相互之间的关系。
课程注册系统的逻辑视图由三个主要的包组成:
用户界面、业务服务和业务对象。
用户接口包包含主角用来同系统通信的各种形式的类。
边界类用于支持登录、维护课程表、维护教授信息、选择课程、提交成绩、维护学生信息、结束注册和查看成绩报告单。
业务服务包包含与财务系统交互、控制学生注册和管理学生评估的控制类。
业务对象包包含大学工件(例如,课程、课程表)的实体类以及同课程目录系统交互的边界类。
1.构架概述—包和子系统的分层
1.用户界面
层
用户界面层包含所有表示用户看到的应用程序屏幕的边界类。
该层依赖于流程对象层,它跨越了客户机和中间层之间的界限。
2.业务服务
层
业务服务流程层包括代表驱动应用程序行为的用例管理器的所有控制器类。
该层代表从客户机到中间层的边界。
业务服务层依赖于流程对象层;它跨越了客户机和中间层之间的分界。
3.业务对象
层
业务对象层包括表示应用程序领域内“事物”的所有实体类。
这些实体类驻留在服务器上,并利用服务类来协助完成它们的职责。
4.系统层
层
系统类在面向对象的系统和由底层系统库支持的功能行为之间提供缓冲区。
系统层包括所有支持安全访问课程注册系统及其数据的类。
5.中间件
层
中间件层支持对关系型DBMS和面向对象的DBMS的访问。
6.java
Java包包括的类支持与远程对象交互的接口、多线程执行和可运行代码。
7.基本复用
基本复用包包括支持列表功能和模式的类。
3.进程视图
关于构架进程视图的说明。
描述了系统运行时涉及到的任务(进程和线程)以及它们之间的交互和配置。
还描述了各种任务的对象和类的分配。
进程模型说明了按可执行进程进行组织的课程注册类。
进程用于支持学生注册、教授功能、结束注册以及对外部财务系统和课程目录系统的访问。
1.进程
图名称:
进程
1.CourseCatalogSystemAccess
该进程管理对遗留课程目录系统的访问。
它可以为多个注册课程的用户所共享。
该进程还允许将最近所检索的课程存储到高速缓冲区以提高性能。
CourseCatalog进程内部的独立线程(即CourseCache和OfferingCache)用于异步检索遗留系统的项目。
分析机制:
-遗留接口
需求的可追踪性:
-设计约束:
系统将与现有的遗留系统(课程目录数据库)集成。
2.CourseCatalog
一个关于课程的完整目录,包括所有课程科目以及大学在以前各个学期所开设的课程。
该类起到适配器的作用(请参照Gamma模式)。
它的作用就是确保能够通过子系统的ICourseCatalogIt接口访问CourseCatalogSystem。
3.CourseRegistrationProcess
对每一个当前正在注册课程的学生,都会产生该进程的一个实例。
4.RegistrationController
其支持的用例允许学生注册本学期的课程。
如果在学期开始的选/退课期间情况发生一些变化,那么学生也可以修改或删除自己所选的课程。
分析机制:
-分布
5.StudentApplication
管理学生功能,包括处理用户界面和同业务流程进行协作。
对每一个当前正在注册课程的学生,都会产生该进程的一个实例。
6.MainStudentForm
控制学生申请的界面。
控制学生使用的一系列表单。
7.FinanceSystemAccess
本进程同外部财务(收费)系统进行通信以启动对学生收费的任务。
8.CloseRegistrationProcess
结束注册进程在注册周期结束时启动。
本进程与控制财务系统访问的进程进行通信。
9.FinanceSystem
财务系统支持提交本学期的学生注册课程收费单。
分析机制:
-遗留接口
10.CloseRegistrationController
结束注册控制器控制对财务系统的访问。
分析机制:
-分布
2.设计元素的进程
图名称:
设计元素的进程
1.StudentApplication
管理学生功能,包括处理用户界面和同业务流程进行协作。
对每一个当前正在注册课程的学生,都会产生该进程的一个实例。
2.MainStudentForm
控制学生申请的界面。
控制学生使用的一系列表单。
3.CourseRegistrationProcess
对每一个当前正在注册课程的学生,都会产生该进程的一个实例。
4.RegistrationController
其支持的用例允许学生注册本学期的课程。
如果在学期开始的选/退课期间情况发生一些变化,那么学生也可以修改或删除自己所选的课程。
分析机制:
-分布
5.CloseRegistrationProcess
结束注册进程在注册周期结束时启动。
本进程与控制财务系统访问的进程进行通信。
6.CloseRegistrationController
结束注册控制器控制对财务系统的访问。
分析机制:
-分布
7.FinanceSystemAccess
本进程同外部财务(收费)系统进行通信以启动对学生收费的任务。
8.FinanceSystem
财务系统支持提交本学期的学生注册课程收费单。
分析机制:
-遗留接口
9.课程
大学提供的某一门课。
分析机制:
-永久性
-遗留接口
10.CourseCatalog
一个关于课程的完整目录,包括所有课程科目以及大学在以前各个学期所开设的课程。
该类起到适配器的作用(请参照Gamma模式)。
它的作用就是确保能够通过子系统的ICourseCatalogIt接口访问CourseCatalogSystem。
11.CourseCache
课程高速缓冲线程用于异步检索遗留课程目录系统的项目。
12.CourseCatalogSystemAccess
该进程管理对遗留课程目录系统的访问。
它可以为多个注册课程的用户所共享。
该进程还允许将最近所检索的课程存储到高速缓冲区以提高性能。
CourseCatalog进程内部的独立线程(即CourseCache和OfferingCache)用于异步检索遗留系统的项目。
分析机制:
-遗留接口
需求的可追踪性:
-设计约束:
系统将与现有的遗留系统(课程目录数据库)集成。
13.OfferingCache
OfferingCashe线程用于异步检索遗留课程目录系统的项目。
14.CourseOffering
某一课程的具体开设情况,包括一周上课的天数和时间。
分析机制:
-永久性
-遗留接口
3.主框架
图名称:
主框架
1.FinanceSystemAccess
本进程同外部财务(收费)系统进行通信以启动对学生收费的任务。
2.CloseRegistrationProcess
结束注册进程在注册周期结束时启动。
本进程与控制财务系统访问的进程进行通信。
3.FinanceSystem
财务系统支持提交本学期的学生注册课程收费单。
分析机制:
-遗留接口
4.CloseRegistrationController
结束注册控制器控制对财务系统的访问。
分析机制:
-分布
5.CourseRegistrationProcess
对每一个当前正在注册课程的学生,都会产生该进程的一个实例。
6.RegistrationController
其支持的用例允许学生注册本学期的课程。
如果在学期开始的选/退课期间情况发生一些变化,那么学生也可以修改或删除自己所选的课程。
分析机制:
-分布
7.StudentApplication
管理学生功能,包括处理用户界面和同业务流程进行协作。
对每一个当前正在注册课程的学生,都会产生该进程的一个实例。
8.MainStudentForm
控制学生申请的界面。
控制学生使用的一系列表单。
9.CourseCatalogSystemAccess
该进程管理对遗留课程目录系统的访问。
它可以为多个注册课程的用户所共享。
该进程还允许将最近所检索的课程存储到高速缓冲区以提高性能。
CourseCatalog进程内部的独立线程(即CourseCache和OfferingCache)用于异步检索遗留系统的项目。
分析机制:
-遗留接口
需求的可追踪性:
-设计约束:
系统将与现有的遗留系统(课程目录数据库)集成。
10.CourseCatalog
一个关于课程的完整目录,包括所有课程科目以及大学在以前各个学期所开设的课程。
该类起到适配器的作用(请参照Gamma模式)。
它的作用就是确保能够通过子系统的ICourseCatalogIt接口访问CourseCatalogSystem。
4.进程模型与设计模型间的依赖关系
图:
进程模型与设计模型间的依赖关系
5.实施进程
图名称:
实施进程
1.ProfessorApplication
控制教授申请的界面。
控制教授使用的一系列表单。
2.StudentApplication
管理学生功能,包括处理用户界面和同业务流程进行协作。
对每一个当前正在注册课程的学生,都会产生该进程的一个实例。
3.CourseRegistrationProcess
对每一个当前正在注册课程的学生,都会产生该进程的一个实例。
4.CloseRegistrationProcess
结束注册进程在注册周期结束时启动。
本进程与控制财务系统访问的进程进行通信。
5.FinanceSystemAccess
本进程同外部财务(收费)系统进行通信以启动对学生收费的任务。
6.Remote
*远程接口用来确认所有的远程对象。
任何作为远程对象的对象都必须直接或者间接地实施该接口。
只有在远程接口中指定的方法才能远程使用。
*实施类可以实施任何数目的远程接口,还可以扩展其它远程实施类。
7.Runnable
*如果一个类的实例确定由某个线程来执行,那么应该由该类来实现Runnable接口。
该类必须定义一个称为run的不调用任何参数的方法。
*该接口设计用于为在那些在活动状态时执行代码的对象提供一个公用的协议。
例如,Runnable由类Thread实现。
*活动状态只不过表示一个线程已经开始,但还没有被停止。
8.OfferingCache
OfferingCashe线程用于异步检索遗留课程目录系统的项目。
9.CourseCatalogSystemAccess
该进程管理对遗留课程目录系统的访问。
它可以为多个注册课程的用户所共享。
该进程还允许将最近所检索的课程存储到高速缓冲区以提高性能。
CourseCatalog进程内部的独立线程(即CourseCache和OfferingCache)用于异步检索遗留系统的项目。
分析机制:
-遗留接口
需求的可追踪性:
-设计约束:
系统将与现有的遗留系统(课程目录数据库)集成。
10.Thread
*thread是在程序中的执行线程。
Java虚拟机允许一个应用程序同时运行多个线程。
*每一线程都有其相应的优先级。
较高优先级的线程要先于较低优先级的线程被执行。
每一个线程可以被标记为一个守护进程,但也可以不这样做。
如果在某个线程中运行的代码创建了一个新的线程对象,则将新线程的优先级最初需要设置为与它的父线程的优先级相同,而且当且仅当父线程是守护进程时它才也是一个守护进程。
11.CourseCache
课程高速缓冲线程用于异步检索遗留课程目录系统的项目。
4.部署视图
构架部署视图的有关说明。
描述了最常用平台配置的不同物理节点。
还描述了如何将任务(从流程视图)分配到物理节点。
该部分按照物理网络配置进行组织;在利用部署图说明每个这样的配置后,接着映射每个处理器的进程。
图名称:
部署视图
1.外部台式PC
学生利用连接到大学服务器的外部台式PC通过internet拨号上网进行课程注册。
2.台式PC
学生利用通过LAN直接连接到大学服务器的本地台式PC进行课程注册。
教授也利用这些本地PC来选择课程和提交学生成绩。
注册员则利用这些本地PC来维护学生和教授信息。
3.注册服务器
注册服务器是大学校园的UNIX主服务器。
所有的教师和学生都可以通过校园LAN来访问该服务器。
4.课程目录
课程目录系统是一个包含有完整课程目录的遗留系统。
通过大学服务器和LAN即可对它进行访问。
5.收费系统
收费系统(也称为财务系统)是一个遗留系统,它生成每个学期的学生收费单。
5.大小和性能
所选的软件构架支持关键性的关于大小确定和时机选择的需求,这一点在补充规约[15]中已有规定。
1.在任意既定时刻,系统最多可支持2000名用户同时使用中央数据库,并在任意时刻最多可支持500名用户同时使用本地服务器。
2.系统将能在十秒钟内提供对遗留课程目录数据库的访问。
3.系统必须能够在2分钟内完成所有事务的80%。
4.客户机程序运行要求的磁盘空间不到20MB,并且内存为32MB。
所选的构架通过客户机服务器构架的实施来支持关于大小确定和时机选择的需求,客户机部分在本地校园PC或远程拨号PC上实现。
构件设计用于确保PC客户机部分需要最少的磁盘空间和内存。
1.质量
软件构架支持质量需求,这一点在补充规约[15]中已有规定。
1.桌面用户界面应与Windows95/98兼容。
2.课程注册系统用户界面的设计应当着眼于易于使用,使具有一定计算机知识的用户群体不需要经过更多的培训就能够使用系统。
3.课程注册系统的每项特性都应具有内置的用户联机帮助。
联机帮助应包括关于系统使用的分步指导。
联机帮助应包括术语和缩写词的定义。
4.课程注册系统在每周七天,每天二十四小时内都应是可以使用的。
宕机的时间应少于4%。
5.平均故障间隔时间应超过三百小时。
6.课程注册系统的PC客户机程序部分的升级可以通过Internet从UNIX服务器上下载。
此功能可以让学生很容易地对系统进行升级。
©1987-2001RationalSoftwareCorporation。
版权所有。
.
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- UML 建模 实例 课程 注册 系统
![提示](https://static.bdocx.com/images/bang_tan.gif)