面向对象分析与设计UML课程设计告1.doc

面向对象分析与设计（UML）课程设计报告设计题目： 饮料自动售货机系统设计 院 系： 计算机学院 专 业： 计算机科学与技术 班级： 计科111 学 号： 090511131、090511133、090511137、090511140 姓 名： 指导教师： 刘永俊 开课时间： 至 学年第 学期常熟理工学院计算机科学与工程学院 制学生姓名 手写签名 成绩 评语： 指导教师（签名） 年 月 日目录1. 设计目的和任务.1.1 主要目的.1.2 主要任务.2. 开发环境.2.1 硬件环境.2.2 软件环境.3. 设计题目.3.1 题目名称.3.2 题目详细描述.3.3 功能要求.4. 相关技术及知识点.4.1 XXX.4.2 XXXXXXXXXX.5. 设计. 5.1系统用例图设计.5.1.1 顾客用例图.5.1.2 送货员用例图.5.1.3 系统用例图. 5.2系统类图设计. 5.3 系统时序图和协作图设计.5.3.1送货员登陆时序图设计.5.3.2送货员添加饮料时序图设计.5.3.3顾客购买饮料时序图设计.5.3.4送货员登陆协作图设计.5.3.5送货员添加饮料协作图设计.5.3.6顾客购买饮料协作图设计.5.4饮料的状态图设计.5.5系统活动图设计.5.5.1顾客活动图设计.5.5.2送货员活动图设计.5.6系统组件图设计.5.7系统配置图设计.6. 总结.7. 参考资料.1. 设计目的和任务1.1主要目的 本课程设计目的是使学生掌握面向对象系统的分析和设计的建模过程。能对学生以后的实际软件开发工作有所指导，也能为日后深入研究本学科奠定一定的基础。课程总目标是帮助学生树立科学的面向对象分析和设计的概念和思想。通过对饮料自动售货机系统管理分析、设计进行建模的实践训练，培养综合的建模设计能力，提高分析和解决问题的能力。1.2主要任务在对所选系统进行深入调查研究的基础上，对系统进行分析和设计，然后通过UML建立模型表达分析和设计结果。 具体任务：1. 对系统进行需求建模，确定系统的参与者及其用例，设计出用例图。2. 对系统进行静态视图建模，确定系统中涉及到哪些类，这些类各有什么属性和方法，以及这些类之间的关系，设计出类图。3. 对系统进行动态视图建模，包括：（1）时序图：选取合适的对象，并设置交互的场景，从而设计出时序图；（2）协作图：可以由对应的时序图转换而来；（3）状态图：找出适合用模型描述其行为的类，然后确定该类的对象可能存在的状态，以及引起状态转换的事件，从而设计出状态图；（4）活动图：找出要对其工作流描述的类或对象，然后确定它有哪些活动，以及这些活动之间的联系，从而设计出活动图。4. 对系统进行组件图建模，确定系统中的组件，组件提供的接口，以及组件之间的以来关系，从而设计出组件图。5. 对系统进行配置图建模，确定系统中的节点、节点之间的关联关系，驻留在节点上的组件及它们之间的依赖关系，从而设计出配置图。2. 开发环境2.1 硬件环境普通个人PC机2.2 软件环境Rational Rose 20033. 设计题目3.1 题目名称饮料自动售货机系统3.2 题目详细描述自动售货机像ATM机一样，以方便、灵活、高档、新颖、文明、昼夜服务等特点，成为当今社会不可缺少的便民配套设施，同时也深受广大市民朋友的青睐。如今的自动售货机可以为顾客提供多种服务，顾客可以根据自己的需要选择商品并投入钱币，售货机接收钱币，售出商品。3.3 功能要求3.3.1 功能模块划分系统送货员查看饮料添加饮料取走钱币查看钱币顾客查看价格付款取消交易选择饮料放置钱币设置价格修改密码3.3.2 功能模块描述该设计模拟自动售货机的工作原理和方式，完成出售商品、接受钱币、找零钱等功能。与系统交涉的人有两类：送货员和顾客。送货员的功能：送货员可以在每周固定时间查看售货机中的饮料数量和钱币数量情况，并根据计划适当添加饮料、钱币或取走适当的钱币。同时，送货员也可以根据需要添加饮料的种类，修改饮料的价格。顾客的功能：顾客可以根据需要饮料，投入钱币，并等待售货机的响应。售货机（所设计的系统）所做的响应：如果售货机中没有该种饮料，则退回顾客所投钱币，交易失败。否则，如果售货机中有该中饮料，则判断顾客所投钱币是否足够，如果不够，则提示顾客交易失败，并退回钱币。如果顾客所投的钱币刚好够（不需要找零钱），则售出饮料，交易结束。如果需要找零钱，则判断是否有适当的零钱可以找，如果有，则售出饮料，找出零钱，交易结束。否则，退回钱币，交易失败。当然，实际生活中的售货机可能有更加强大的功能和更完善的处理，这里只模拟一个售货机系统，所以只实现其核心功能。4. 相关技术及知识点4.1 UML建模相关技术UML建模技术就是用模型元素来组建整个系统的模型，模型元素包括系统中的类、类和类之间的关联、类的实例相互配合实现系统的动态行为等。UML提供了多种图形可视化描述模型元素，同一个模型元素可能会出现在多个图中对应多个图形元素，可以从多个视图来考察模型。UML建模技术主要分为结构建模、动态建模和模型管理建模3个方面：第1个方面是从系统的内部结构和静态角度来描述系统的，在静态视图、用例视图、实施视图和配置视图中适用，采用了类图、用例图、组件图和配置图等图形。例如类图用于描述系统中各类的内部结构（类的属性和操作）及相互间的关联、聚合和依赖等关系，包图用于描述系统的分层结构等；第2个方面是从系统中对象的动态行为和组成对象间的相互作用、消息传递来描述系统的，在状态机视图、活动视图和交互视图中适用，采用了状态机图、活动图、顺序图和合作图等图形，例如状态机图用于一个系统或对象从产生到结束或从构造到清除所处的一系列不同的状态；第3个方面描述如何将模型自身组织到高层单元，在模型管理视图中适用，采用的图形是类图。建模的工作集中在前两方面，而且并非所有图形元素都适用或需要采用。4.2视图设计相关知识点用例图用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供的服务。用例图最常用来描述系统以及子系统。 用例图包含6个元素：参与者（Actor）、用例（Use Case）、关联关系（Association）、包含关系（Include）、扩展关系（Extend）、泛化关系（Generalization）对需求建模 ：（1） 识别系统的外部参与者来建立系统的语境；（2） 考虑每一个参与者期望的行为或需要系统提供的行为；（3） 把这些公共的行为命名为用例；（4） 确定提供者用例和扩展用例；（5） 对这些用例、参与者和它们之间的关系建模；（6） 用注释修饰用例。类图类图描述类、接口、协作及它们之间关系的图；类图显示系统中各个类的静态结构。类图的元素：类（Class）、接口（Interface）、协作（Collaboration）、依赖关系（Dependency）、泛化关系（Generalization）、关联关系（Association）、实现关系（Realization）。时序图与协作图时序图是强调消息时间顺序的交互图。时序图描述了对象之间传送消息的时间顺序，用来表示用例中的行为顺序。时序图将交互关系表示为一个二维图。其中，纵轴是时间轴，时间沿竖线向下延伸。横轴代表了在协作中各独立的对象。 时序图包含了4个元素：对象（Object）、生命线（Lifeline）、消息（Message）、激活（Activation）。时序图建模技术：（1） 设置交互的语境；（2） 通过识别对象在交互中扮演的角色，设置交互的场景；（3） 为每个对象设置生命线；（4） 从引发某个消息的信息开始，在生命线之间画出从顶到底依次展开的消息，显示每个消息的特性（如参数）；（5） 如果需要可视化消息的嵌套或实际计算发生时的时间点，可以用激活修饰每个对象的生命期；（6） 如果需要说明时间或空间的约束，可以用时间标记修饰每个消息，并附上合适的时间和空间约束；（7） 如果需要更形式化的说明某控制流，可以为每个消息附上前置和后置条件。协作图描述的是和对象结构相关的信息，用途是表示一个类操作的实现。协作图是对交互中有意义的对象和对象之间的链建模。协作图包含了3个元素：对象（Object）、链（Link）、消息（Message）协作图建模技术：（1） 设置交互的语境；（2） 通过识别对象在交互中扮演的角色，设置交互的场景；（3） 对每个对象设置初始特性；（4） 描述对象之间可能有信息沿着它传递的链；（5） 从引起交互的消息开始，适当地设置其顺序号，然后将随后的每个消息附到适当的链上；（6） 如果需要说明时间或空间约束，可以用时间标记修饰这个消息，并附上合适的时间和空间约束；（7） 如果需要更形式化地说明这个控制流，可以为每个消息附上前置和后置条件。协作图和时序图可以互换而不损失任何消息。状态图与活动图状态机包含了一个类的对象在其生命期间所有状态的序列以及对象对接受到的事件所产生的反应。利用状态机可以精确地描述对象的行为。活动图与状态图都是状态机的表现形式。状态图建模技术：（1） 找出适合用模型描述其行为的类；（2） 确定对象可能存在的状态；（3） 确定引起状态转换的事件；（4） 确定转换进行时对象执行的相应动作；（5） 对建模的结果进行相应的精化和细化。活动图建模技术：（1） 识别要对其工作流描述的类或对象；（2） 确定工作流的初始状态和终止状态，明确工作流的边界；（3） 对动作状态或活动状态建模；（4） 对动作流建模；（5） 对对象流建模；（6） 对建立的模型进行精化和细化。 活动图与状态图的区别：活动图着重表现从一个活动到另一个活动的控制流，是内部处理驱动的流程；状态图着重描述从一个状态到另一个状态的流程，主要有外部事件的参与。 组件图组件图描述了软件的各种组件和它们之间的依赖关系。组件图中通常包含3个元素：组件（Component）、接口（Interface）、依赖关系（Dependency）。组件图建模技术：（1） 对系统中的组件建模；（2） 对相应组件提供的接口建模；（3） 对组件之间的依赖关系建模；（4） 将逻辑设计映射成物理实现；（5） 对建模的结果进行精化和细化。 配置图配置图描述了运行软件的系统中硬件和软件的物理结构。配置图建模技术：（1） 对系统中的节点建模；（2） 对节点之间的关联关系建模；（3） 对驻留在节点上的组件建模；（4） 对驻留在节点上的组件之间的依赖关系建模；（5） 对建模的结果进行精化和细化。5. 设计 5.1系统用例图设计5.1.1顾客用例图设计顾客用例图如图5-1所示图5-1 顾客用例图顾客参与者可以执行选择饮料、付款、取消交易三种操作。5.1.2送货员用例图设计送货员用例图如图5-2所示图5-2 送货员用例图送货员参与者执行登录系统、设置价格、查看饮料、添加饮料、查看钱币、放置钱币、取走钱币、修改密码等操作。5.1.3系统用例图设计系统用例图如图5-3所示图5-3 系统用例图整个系统共有用户、顾客和送货员三个参与者，其中顾客和送货员均属于用户这个参与者，共同有查看价格这个操作；同时这两个参与者有各自的不同操作。5.2系统的类图设计 系统的类图如图5-4所示图5-4 系统的类图整个系统中由用户这个父类派生出送货员和顾客两个子类，且均继承父类的查看价格方法，同时各自有不同的属性和方法。送货员类依赖身份认证类，送货员需通过身份验证才能进入送货员界面，实现其他的功能。送货员类还依赖钱币类，才能实现查看钱币、取走钱币等功能。顾客类依赖饮料类，才能实现选择饮料的功能。销售类依赖自钱币类和饮料类，这样才能实现销售饮料、找零等功能。另外，送货员类、销售类都依赖数据库类，因为这些信息都是存放在数据库中的。5.3系统时序图和协作图设计5.3.1 送货员登陆时序图设计送货员登陆时序图如图5-5所示图5-5 送货员登陆时序图送货员在送货员界面输入用户名和密码信息，系统接收信息进行身份认证，在数据库中查找相应的用户名和密码信息，进行比较；若错误则返回登录失败的信息，反之登陆成功则返回登陆成功的信息。5.3.2送货员添加饮料时序图设计送货员添加饮料时序图如图5-6所示图5-6 送货员添加饮料时序图送货员界面接受送货员发送的关于饮料种类和数量的输入信息，并将信息传送给销售，数据库根据信息及时修改饮料数量，同时销售返回现有饮料数量的信息。5.3.3顾客购买饮料的时序图设计顾客购买饮料的时序图如图5-7所示图5-7 顾客购买饮料的时序图顾客在顾客界面选择饮料并投币，销售系统获取顾客付款。销售系统访问数据库查看该种饮料是否有余量，如果已经卖完，则提示售空并退回钱币。否则，在数据库中查询该种饮料的价格，并判断顾客所投钱币是否够买该饮料。如果不够，则提示付款不够，并退回钱币。如果足够，则计算需要找的零钱，并在数据库中查询是否有足够的零钱。如果没有适合的零钱，则提示并退回顾客所投钱币。如果有适合的零钱，则通知数据库更新饮料和钱币信息，并且售出饮料，找零。5.3.4送货员登陆协作图送货员登陆协作图如图5-8所示图5-8 送货员登陆协作图实现功能与对应时序图（图5-5）一样。5.3.5送货员添加饮料协作图送货员添加饮料协作图如图5-9所示图5-9 送货员添加饮料协作图实现功能与对应时序图（图5-6）一样。5.3.6顾客购买饮料协作图顾客购买饮料协作图如图5-10所示、图5-10 顾客购买饮料协作图实现功能与对应时序图（图5-7）一样。5.4饮料的状态图设计饮料的状态图如图5-11所示图5-11 饮料的状态图新的饮料在售货机中为可售出的饮料，顾客选择后为被选中的饮料，一旦顾客付款则为被售出的饮料，若取消选择则还是可售出的饮料；若售货机中的饮料为售空状态，送货员可以添加饮料，则为该种饮料又变为可售出饮料的状态，最后为过期的饮料的状态。5.5系统活动图设计5.5.1顾客活动图设计顾客和送货员活动图如图5-12所示图5-12 顾客和送货员活动图顾客进入顾客界面后，可以查看饮料的价格，然后投入钱币或选择饮料，在这两个动作都完成后，饮料机会检查顾客选中的该种饮料是否售空，若已售空，则在界面显示售空，并退款给顾客，同时交易结束；若没有售空，则检查饮料的价格，如果投入的金额小于饮料的价格，则显示金额不足，并且退款，同时交易结束；否则，检查找零，若没有足够的零钱，则显示零钱不够，并且退款，同时交易结束；若有足够的零钱，则找零并售出饮料，然后交易结束。5.5.2送货员活动图设计送货员活动图如图5-12所示图5-12 送货员活动图送货员对售货机操作的活动图，通过与数据库的交互，完成了一系列活动，包括查看售货机的钱币和饮料信息，并适时地修改这些信息。5.6系统组件图设计系统组件图如图5-12所示图5-12 系统组件图5.7系统配置图设计系统配置图如图5-12所示图5-12 系统配置图6. 总结实际生活中的售货机可能有更加强大的功能和更完善的处理机制，我们在这里只模拟了一个售货机系统，所以只实现了其核心原理，着重在于巩固已学的UML建模思想内容、提高对相关问题的分析与解决能力。通过对饮料自动售货机系统的设计，从最开始考虑需求、系统分析再到详细设计，对软件开发的整个过程有了更清晰的认识和了解。通过运用Rational Rose来对系统整体和模块部分进行设计，对UML统一建模语言有了更深的理解。当用例图在用户前出现时，它捕获到系统、子系统或类的行为。它将系统功能划分成对参与者有用的需求。而交互功能部分被称作用例。用例使用系统与一个或多个参与