UML电影售票系统.doc

《UML电影售票系统.doc》由会员分享，可在线阅读，更多相关《UML电影售票系统.doc（26页珍藏版）》请在三一文库上搜索。

1、软件系统建模与UML课程设计报告设计题目： 电影院售票系统 院 系： 计算机 专 业： 班级： 学 号： 姓 名： 指导教师： 设计地点： 常熟理工学院计算机科学与工程学院 制学生姓名 成绩 评语： 指导教师（签名） 年 月 日目录1. 设计目的和任务.22. 开发环境.22.1 硬件环境.22.2 软件环境.33.设计题目.33.1 题目名称.33.2 题目详细描述.33.3 功能要求.34. 相关技术及知识点.44.1 用例建模.4.2 用例的定义.4.3构造用例图的步骤.4.4 RUP的核心工作流. 4.5概念模型. 4.6概念模型作用. 4.7类图. 4.8类的三个层次. 4.9如何建

2、立关联. 4.10系统行为. 4.11图. 4.12契约. 4.13协作图. 4.14三层结构的优势.5. 面向对象分析与设计.7 5.1 用例图. 5.2 概念模型. 5.3系统类. 5.4契约. 5.5协作图. 5.6系统类图. 5.7状态图. 5.8系统组件图. 5.9部署图. 5.10数据库表.6. 双向工程.87. 总结.98. 参考资料.一 设计目的和任务1.1设计目的通过自身对电影院的了解和经历、分析以及实际的市场调查，要求本系统具有以下功能：（1）、统一友好的操作界面，能保证系统的易用性。（2）、规范、完善的基础信息设置。（3）、影片分类详尽，可按不同类别查看影片信息。（5）、

3、实现轻松便捷购买影票。 为了影院售票系统更完善；为了影院对售票的管理更方便。1.2设计任务 在明确系统功能点后，按授课要求，请用面向对象分析设计的方法设计系统，参考RUP的流程，依次得出系统的参与者、用例图、概念模型、系统类并定义系统类操作的契约、协作图（请考虑三层架构的设计方式）、得出系统的类图、数据库表，对得出的各种UML图需要进行文字描叙。二 开发环境2.1 硬件环境 微机一台、打印机一台、扫描仪一台2.2 软件环境操作系统：WindowsXP； 数据库：MYSQL。三.设计题目3.1 题目名称 电影院售票系统3.2 题目详细描述 售票管理系统是一个基于电影院工作人员的系统，不同类型的用

4、户在系统中有不同的权限。主要有两种用户： 购票者：可以查询电影的上映时间，场次，并选择自己所需要的电影票，向售票员购买电影票。 管理员：主要负责将电影信息增加，修改，删除，并导入数据库。 3.3 功能要求 （1）系统总体的功能需求影院售票系统是一个复杂的电子商务系统，它必须提供用户的接口以供用户登录并选择影票；同时还必须提供系统的管理接口以供管理员和一般的网站工作人员处理客户订单并维护网站正常运作。 图3-3-1 系统总体功能需求框图 （2）用户接口模块用户接口是网站用户使用影院售票系统服务的入口，所有的在线用户都通过浏览登录网站，并进行一系列的查询，订购操作。用户接口模块包括了用户信息维护、

5、商品查询、订购商品和订单维护4个部分。用户登录系统后，用户ID将会被保存在服务器的缓存中，用户在系统中所做的操作，包括查询、订购等都将被系统存储在数据库中，以供系统那个进行销售情况以及销售走势分析。 （3）管理员接口模块这是系统提供给网站维护和管理人员的接口。管理员接口模块包括商品信息维护、内部员工信息维护、订单处理、销售情况查询、报表维护5个部分。网站的一般工作人员通常只具有订单处理的权限，他们获得用户提交的订单，并根据库存情况来决定发货或者推迟发货。网站的管理员具有所有的管理权限，可以处理客户的订单，可以阅览网站商品的销售情况、销售走势，以便根据不同的情况及时的调整经营战略，将库存成本和资

6、金占有用率降到最低的限度。 （4）数据服务模块数据服务器模块是系统正常运行的基础，包括客户的查询，定单的保存；网站工作人员的定单处理；网站管理员的销售情况查询与分析。四 相关技术及知识点4.1 用例建模用例建模是需求工程的一种形式，是抽取和文档化需求的补充方法相对于“传统”SRS方法用例是Jacobson在面向对象的软件工程中提出的，但它实际上是独立于面向对象的。典型用例建模方法：找出系统边界。找出参与者。找出用例(包括说明用例，创建场景)4.2 用例的定义 定义：由系统执行的一个动作序列，并能产生可观测的结果值给特定的角色。如：从ATM机提取现金；定购一个商品； 从学校选课系统注册选课；从文

7、本编辑器中检查一个文档的拼写错误；用例命名：(状语）动词（定语）宾语4.3构造用例图的步骤1.确定系统的上下文： 1.1 确定参与者与它们的责任； 1.2 确定用例，即确定带有某种目的或产生特定结果的系统行为。2.对参与者和用例进行权衡，以便精化模型，例如拆分和合并定义。3.衡量用例以找出包含关系。4.衡量用例以找出扩展关系。5.对参与者和用例进行研究，查找是否存在泛化关系。4.4 RUP的核心工作流 （1）6个核心工程工作流： 需求工作流 分析和设计工作流 实现工作流 测试工作流 分发工作流 （2）3个核心支持工作流： 项目管理工作流 配置和变更控制工作流 环境工作流4.5概念模型 概念模型

8、：展现了问题域中有意义的概念，是OOA中要得到的最重要的制品。是真实世界中各个事物的代表，而不是软件中各个构件的代表。概念模型包括：1、一组概念；2、概念之间的关联；3、概念的属性；4.6概念模型作用 概念模型的作用：将问题域空间分解成小的单元（概念）；帮助澄清领域中的术语和词汇（有哪些重要术语、以及术语之间的关系如何）。4.7类图 类图描述了系统中的类及其相互之间的各种关系。类之间的关系表示了对象之间的通信能力。类之间有三种关系：关联（包括聚合和组合）继承依赖4.8类的三个层次Conceptual：概念层。描述问题域中的概念，不考虑或很少考虑实现上的细节No Software。只考虑属性，在

9、分析阶段使用。Specification：说明层。Looking into Software,but only interface of the software, not the implementation. Only type, not class。增加操作定义，在设计阶段使用。Implementation: 实现层。只有当使用某一具体技术进行设计时使用。在设计阶段使用。4.9如何建立关联 添加关联应细到什么程度1、在建立概念模型时主要时间花费在识别问题域概念上，而不是识别关联上。2、关联太多不仅不能有效展示概念模型，反而会使模型混乱。3、概念模型概念间的关联是从纯分析角度声明有意义的概

10、念间的联系，不需要考虑如何实现关联。4、分析阶段得到的关联可能在设计阶段发现是无用的；设计阶段有可能发现分析阶段遗漏了有些概念间的关联。4.10系统行为 在进行系统逻辑设计之前，必须先调查系统的行为，即将系统看作一个黑盒子，描述系统要“做什么”，而不是“怎么做”。定义系统行为的两种手段：系统顺序图和契约。4.11图 展示了一个特殊的用例场景中外部参与者发起的事件以及事件的顺序。在顺序图中，所有的系统都被当成黑盒子对待，顺序图的重点是参与者发起的跨越系统边界的事件。建立系统顺序图要依赖于前面已经建立起来的用例描述。4.12契约 契约是一个文档，描述系统操作对系统状态的影响，属于系统行为建模的一部

11、分。契约强调发生了什么而不是怎么发生。 流程：用例描述系统顺序图系统操作契约 契约文本描述中强调操作的职责和后置条件实用的契约后置条件分为以下三类：1、实例的创建和销毁。2、属性的修改。3、关联的形成和破裂。后置条件的表达要符合概念模型的语境，通过后置条件能发现概念模型遗漏的概念、属性或关联，从而进行补充。4.13协作图1、每一个系统操作建立一张协作图，其中每个系统操作作为这张单独的图的起始消息。2、若所绘出的图太复杂，那么可以将这个大图分成若干小图。3、使用操作契约和契约的后置条件以及用例描述文档作为起点来设计系统。识别对象、给对象分配职责、利用GRASP和系统模式来优化设计。4.14三层结

12、构的优势1便于统一安装和维护，客户端几乎零维护。2表示层、应用逻辑层、存储层比较独立，可以分别进行修改和升级。3便于组件共享和升级。4方便对应用逻辑单独进行升级和修改。5可以采用中间件技术，实现负载平衡。6在复杂情况下具有很高的运行效率和稳定性。7完整的事物处理能力和简单的编程接口。8简化应用逻辑的编程，不关心存储的细节。五 面向对象分析与设计 5.1 用例图 （1）管理员用例图 5-1-1 管理员用例图用例说明 1.简要说明本用例描述管理人员管理电影院的过程 2.时间流 1.基本流 1.管理人员在数据服务器上管理电影信息（修改，添加，删除） 2.将管理人员所做的改动返回数据服务器 3.系统保

13、存管理人员所做改动，并备份原数据 2.备选流 无2. 特殊要求 无3. 前置条件 执“登陆”用例4. 后置条件 无5. 扩展点 无6. 相关数据（2）购票者用例图 5-1-2购票者用例图1. 简要说明 本用例描述购票者购票的过程2. 事件流1.基本流 1.购票者查看电影信息来确认电影的名字，价格，上映时间。 2 .购票者通过购票系统来选择 电影与剩余可选的座位。 3. 购票者通过购票系统向售票者购买电影票。 4，系统确认购票者的请求并由售票员收取费用。7. 备选流 2a如果购票者想要购买的电影场次票已售完，给出提示，并返回。 4a如果售票者确认购票者的请求失败，给出提示，并返回。 3.特殊需求

14、 无 4前置条件 无 5后置条件 无 6 扩展点 无 7,相关数据 . 电影信息5.2 概念模型5-2-1系统概念模型 购票者与电影信息和电影票之间有关联；电影信息和管理员之间有关联。5.3系统类购票者类 管理员类 电影信息类 电影票类 购票者的属性：姓名，年龄，电话管理员的属性：ID PASSWORD电影信息的属性：名称，导演，主演，价格，时间电影票的属性：名称，价格，时间5.4契约（1）订购电影票的契约 5-4-1订购电影票的系统顺序图和系统操作 契约1名称初始化职责让用户登录系统交叉引用用例：订购电影票注释异常输出前置条件后置条件提示用户成功登录 契约2名称查询职责显示各种影片信息供购票

15、者选择交叉引用用例：订购电影票注释异常输出前置条件用户成功登录后置条件提示是否订购 契约3名称订购职责生成电影票交叉引用用例：订购电影票注释异常输出前置条件用户成功登录后置条件提示订购成功 契约4名称保存退出职责把数据存入数据库，退出系统交叉引用用例：订购电影票注释异常输出前置条件订购成功后置条件提示订票成功 （2）管理电影信息的契约5-4-2管理电影信息的系统顺序图和系统操作 1契约名称初始化职责供管理员登入系统交叉引用用例：管理电影信息注释异常输出前置条件后置条件提示成功登录 2 契约名称修改增加删除职责让管理员可以对现有的电影信息进行修改，增加，删除交叉引用用例：管理电影信息注释异常输出

16、前置条件管理员成功登录系统后置条件提示是否保存 3 契约名称保存退出职责把修改后的数据存入数据库，退出系统交叉引用用例：管理电影信息注释异常输出前置条件管理员成功登录系统后置条件提示电影信息修改成功5.5系统协作图（1）购票者协作图 5-5-1购票者协作图 Title：相关电影信息Item：更新后的电影信息显示相互合作的对象之间的交互和链接关系： 1：用户登录系统 2：订票系统查询已有的电影信息 3：订票系统处理订票信息 4：检查该电影座位数是否减少 5：订票 6：更新座位信息 （2） 管理员协作图5-5-2 管理员协作图 Title：相关电影信息 Item：更新后的电影信息显示相互合作的对象

17、之间的交互和链接关系：1:管理员验证购票者身份信息2：售票系统查询订单信息3：找到订购电影票的信息4：出售电影票5：检查是否超过最大座位6：售票7：更新电影信息5.6 系统类图5-6-1 系统类图 一个管理员可以处理多个电影信息；一个购票者可以购买多张电影票；一个购票者对应一个付款记录；多个订购单对应多个电影信息。5.7状态图（1） 订票状态图 5-7-1订票状态图New FILM: 新电影Available：处于可购买状态Delete：删除Time_out：超过时间Cancle：购票者取消Reserve：保存信息Bought：购买（2）售票状态图 5-7-2售票状态图New buyer：新的

18、购买者New state：新的数据Account unavailable：订单不可交易Delete account：删除订单5.8系统组件图5-8-1系统组件图5.9部署图 5-9-1 部署图Database：数据库服务器Web application：网络应用Business operation：交易操作Information maintenance：信息维护5.10数据库表（1） 电影信息数据库表字段名称数据类型 字段属性字段大小名称必填字段是否主键nameNvarchar50电影名称是是directorNvarchar50导演否performerNvarchar50主演否 5-10-1电

19、影信息数据库表（2） 电影票数据库表字段名称数据类型 字段属性字段大小名称必填字段是否主键nameNvarchar50电影名称是是directorNvarchar50导演否performerNvarchar50主演否pricefloat8价格是seatnumbersmallint2座位号是5-10-2 电影票数据库表 六 双向工程 由于所有图都是由VISIO软件所绘，没有双向工程的功能，所以无法像ROSE一样能够产生系统的部分代码。七 总结 经过好几天的时间进行的学习UML相关知识，查阅大量资料，辛苦一番后，终于成功的得出了用例图，概念模型，操作顺序图，契约，系统协作图和系统类图的绘制。在整个流程中，不断的遇到各种困难，通过不懈的努力，解决了大大小小的问题，从中学到很多以前忽视的知识，受益匪浅。在整个过程中，从头到尾的UML设计过程中，对UML有了一个更深的印象和体会，这对以后的学习和工作都带来相当大的益处。事实表明UML是目前计算机发展的一个相当火热的焦点，所以我们应该好好学习UML相关知识。 八. 参考资料1 国刚，周峰，孙更新，UML与Rational Rose 2003，电子工业出版社，2007年4月