UML与软件建模实验报告
UML建模实验报告02
UML建模实验报告02UML建模实验报告021.实验目的本实验的目的是通过实际项目案例，了解和掌握使用UML建模工具进行软件系统建模的过程和方法。
2.实验过程本次实验我们选择了一个简单的在线购物系统作为项目案例。
首先，我们进行了需求分析，确定了系统的功能和特性。
然后，我们进行了领域建模，识别出了系统的核心概念和实体。
接下来，我们进行了用例建模，识别出了系统的用例，并绘制了用例图。
然后，我们进行了行为建模，设计了系统的顺序图和活动图。
最后，我们进行了结构建模，设计了系统的类图和对象图。
3.实验结果通过本次实验，我们成功完成了在线购物系统的建模过程，并获得了以下结果：1)需求分析：我们确定了系统的功能和特性，包括用户登录、浏览商品、添加到购物车、下订单等。
2)领域建模：我们识别了系统的核心概念和实体，包括用户、商品、购物车、订单等，并绘制了类图。
3)用例建模：我们识别了系统的用例，并绘制了用例图，包括登录、浏览商品、添加到购物车、下订单等。
4)行为建模：我们设计了系统的顺序图和活动图，包括用户登录、浏览商品、添加到购物车、下订单等的流程和交互。
5)结构建模：我们设计了系统的类图和对象图，识别了系统的类和对象，包括用户、商品、购物车、订单等。
4.实验总结通过本次实验，我们深入了解和体验了使用UML建模工具进行软件系统建模的过程和方法。
我们发现UML建模工具可以很好地帮助我们理清系统的功能和特性，识别出系统的核心概念和实体，设计系统的用例、顺序图、活动图、类图和对象图。
通过建模过程，我们可以更加清晰地理解系统的需求和设计，并与团队成员进行有效的沟通和协作。
同时，我们也发现UML建模工具的使用需要一定的学习和实践，尤其是对于一些高级建模概念和技术的掌握。
因此，我们认为在今后的实践中，需要进一步学习和应用UML建模工具，以提高我们的建模能力和技术水平。
5.实验改进建议根据本次实验的经验和总结，我们提出以下改进建议：1)在实验前进行必要的学习和准备，了解UML建模工具的基本概念和使用方法，以充分发挥工具的功能和效能。
UML实验报告全
UML实验报告全实验报告：UML建模实验一、实验目的本实验旨在帮助学生掌握UML（统一建模语言）的基本概念、用法和建模过程，提高学生的软件建模能力。
二、实验内容1.了解UML的基本概念和用法；2.学习UML的各种图表，包括用例图、类图、序列图等；3.理解UML的建模过程，并能够按照该过程进行软件建模。
三、实验步骤1.学习UML的基本概念和用法。
在实验前，学生需要预习UML的基本知识，包括UML的定义、分类、语法规则等。
2.学习UML的各种图表。
UML提供了多种图表用于软件建模，如用例图、类图、对象图、活动图、状态图等。
学生需要了解每种图表的用途、语法和示例。
3.理解UML的建模过程。
在实际项目中，使用UML进行软件建模有一定的步骤，包括需求分析、设计、实现等。
学生需要了解UML的建模过程，并能够按照该过程进行实际建模。
4.实际操作。
学生需要选择一个简单的软件项目进行建模实践，包括绘制用例图、类图、序列图等，并撰写相应的文档。
5.分析和总结。
学生需要对实际操作进行分析和总结，包括建模过程中的问题和解决方法等，以便提高建模能力。
四、实验结果在本次实验中，我选择了一个简单的图书管理系统作为建模实践对象。
首先，我绘制了该系统的用例图，用于描述系统的功能和用户角色。
然后，我绘制了该系统的类图，用于描述系统的数据结构和类之间的关系。
最后，我绘制了该系统的序列图，用于描述系统中对象之间的交互过程。
在实际操作中，我遇到了一些问题。
首先，我发现在绘制用例图时，有些用例的描述不够清晰，无法准确描述用户需求。
为了解决这个问题，我与用户进行了沟通，并修改了用例的描述，使其更加明确。
其次，在绘制类图时，我发现有些类的关系没有考虑到，导致系统的完整性受到了影响。
为了解决这个问题，我仔细分析了系统的数据结构，并修改了类的关系，使其更加准确。
通过本次实验，我学到了很多关于UML建模的知识和技巧。
我发现UML是一种非常强大和灵活的建模语言，可以帮助我们更好地理解和设计软件系统。
软 件 建 模 与 UML 实 验 报 告 网上图书销售系统
软件建模与UML 实验报告网上图书销售系统学院：计算机学院专业班级：计科0903班姓名：李宏媛学号：0908030308日期：2012年12月5日网上图书销售系统一、实验目的与要求通过一个具体的、完整的建模系统实例，加深对UML的理解与掌握。
二、实验内容首先，对网上图书销售系统系统进行需求分析，然后，在此基础之上完成对该系统的建模工作。
三、实验步骤1：系统的总体功能需求网上图书销售系统是一个复杂的电子商务系统，它必须提供用户的接口以及用户登录并选择喜好的图书；同时还必须提供系统的管理接口以供管理员和一般的网站工作人员处理客户订单并维护网站正常运作。
系统总体功能需求框图如下所示。
(1)用户接口模块：用户接口是网站用户使用图书销售系统服务的入口，所有的在线用户都通过浏览器登网站，进行查询，订购操作。
此模块包括了用户信息维护，商品查询，订购商品和订单维护4个部分。
(2)管理员接口模块：管理员接口是系统提供给网站维护和管理人员的接口。
此模块包商品信息维护，内部员工信息维护，订单处理，销售情况查询，报表维护5个部分。
其中一般工作人员只有订单处理的权限，而管理员具有所有的管理权限。
（3）数据服务模块：数据服务是系统正常运行的基础，包括客户的查询，订单的保存；网站工作人员的订单处理；网站管理员的销售情况查询和分析。
2、系统的用例图确定参与者：在本系统的UML建模中，可以创建的参与者包括顾客，管理员，一般员工创建用例：根据业务流程，本系统的用例包括：订单处理，订单维护，订单状态查询，个人信息维护;订购；接收发货；库存查询；缺货拒绝；商品查询;商品信息维护；销售查询；员工信息维护；报表维护；订单增加；订单删除。
1）、创建用例图，管理员和员工的用例图如下所示2）、顾客的用例图，如下所示：3、系统的活动图顾客购买商品和管理员处理订单的活动图如图所示：4、系统中的类（1）参与者相关的类系统中和参与者相关的类的类图如下：（2）各类之间的关系类不是单独一个模块，各个类之间是存在联系。
uml实验报告
uml实验报告UML实验报告。
一、实验目的。
本实验旨在通过对UML（Unified Modeling Language，统一建模语言）的学习和实践，掌握UML的基本概念、语法和建模方法，能够运用UML对系统进行分析、设计和建模。
二、实验内容。
1. 了解UML的基本概念和发展历程；2. 掌握UML的基本语法和建模元素；3. 学习使用UML对系统进行需求分析、概念建模、系统设计和详细设计。
三、实验过程。
1. UML基本概念和发展历程。
UML是一种用于软件开发的建模语言，它提供了一种统一的、标准的建模方法，可以帮助软件开发人员进行系统分析和设计。
UML的发展经历了多个版本的更新和完善，目前最新的版本是UML 2.x。
通过学习UML的基本概念和发展历程，我们对UML有了更深入的了解，为后续的学习和实践打下了基础。
2. UML的基本语法和建模元素。
UML包括了多种建模元素，如用例图、类图、时序图、活动图等。
每种建模元素都有其特定的语法和符号表示方法，通过学习这些基本语法和建模元素，我们能够准确地使用UML对系统进行建模和描述。
3. 使用UML进行系统分析、设计和建模。
在掌握了UML的基本语法和建模元素后，我们开始了对系统的分析、设计和建模工作。
首先，我们对系统进行了需求分析，明确了系统的功能和性能需求；然后，我们进行了概念建模，绘制了用例图和类图；接着，我们进行了系统设计，绘制了时序图和活动图；最后，我们进行了详细设计，完善了系统的各项细节。
四、实验总结。
通过本次实验，我们深入学习了UML的基本概念、语法和建模方法，掌握了使用UML进行系统分析、设计和建模的技能。
在实践中，我们对UML的各种建模元素有了更深入的理解，能够准确地运用UML对系统进行描述和设计。
同时，我们也意识到UML是一个非常强大和实用的工具，能够帮助我们更好地进行软件开发和项目管理。
综上所述，本次实验对我们的学习和成长都具有重要意义，我们将继续深入学习和实践UML，不断提升自己的建模能力和软件开发水平。
uml实验报告(7)
当车辆全部投入使用，并没有车辆空闲，也会终止交易！
如果顾客的以往记录很差，员工拒绝租车给顾客，不再进行交易！
2）最终的活动图（粘贴在下面）
五、实验结果与分析（含程序、数据记录及分析和实验总结等）：
尽管活动图与状态图、交互图有类似之处，工作人员和客户的行为表示也差不多，但也有不同之处，活动图是可以吧不同对象同时进行相关操作的，可以进行分支描述。
六：思考题：
2、根据案例绘制出该系统的活动图
四、实验步骤：
（对实验步骤的说明应该能够保证根据该说明即可重复完整的实验内容，得到正确结果。）
1、请表填写，并发送保存；一方面，员工定时进行请求查看，当有新的请求时，员工会先查看顾客以往记录，日光顾客以往记录良好，又有车辆空闲时，会向顾客发送接受请求的信息，顾客去取得车辆，使用后归还。
UML与系统建模实验报告
实验名称：
实验七、根据案例绘制系统的活动图
班级：
姓名：
学号：
类型：
综合
实验地点：
日期：
一、实验目的：
1.会对案例进行分析，抽象出其中的活动图模型
2.能使用Rose软件绘制出案例的活动图
二、实验环境：
1.PC机一台（带有Rose软件）
三、实验内容和要求：
1、理解所给的案例（见PPT）
UML与软件建模实验报告
《UML与软件建模》实验报告书专业班级计算机科学与技术XX学号123456789姓名Jackiy Brown指导教师XXXXX安徽工业大学计算机学院实验一、用例建模【实验日期】2012年3月12日【实验目的】●掌握客户需求分析的方法和步骤●了解以用例建模的软件开发方法●识别并编写用例●掌握用Rose进行用例建模的具体方法和步骤【实验内容】要求根据周围的实际情况，自选一个小型应用项目，分析业务需要，识别并编写用例、绘制用例图以理解系统需求，亦可老师指定的“企业综合信息管理系统”中的“进销存管理子系统”【实验原理与步骤】建模原理：1.需求获取，以任务和客户为中心，通过会议、面谈等手段对客户需求进行调研，获得系统目标、范围和功能要求的初步说明。
2.用例分析，确定用例，同时采用分层思想，对用例的层次级别进行划分（高层用例、子系统级、用户目标级）3.用例描述。
分层绘制用例图，撰写用例的文字描述（采用单栏格式）。
步骤：1.需求获取。
自选题目，与相关客户、领域专家等反复商讨，获得系统目标、范围和功能要求的初步说明。
（也可采用老师指定的题目：“企业综合信息管理系统”中的“进销存管理子系统”）。
2.用例分析。
确定系统范围和边界、确定参与者、确定用例。
3.用例描述。
分层绘制用例图，描述用例。
画图原理：采用Rose软件进行用例建模必须建立在完好的系统用例分析基础之上，只有做好系统分析，系统用例建模才能达到预期的效果。
步骤：1.分层绘制用例图，每层采用“包”进行管理。
2.以“企业综合信息管理系统”—》“进销存管理”子系统—》“销售管理”—》“合同管理”—》“收款单处理”为主线，完成实验。
其他主线也可以。
【实验结果】1.用Rose绘制的“企业综合信息管理系统”的1级用例图如下：此系统包括“财务管理子系统”、“综合支持管理子系统”、“生产调试管理子系统”和“经理查询子系统”等，而“进销存管理子系统”又包括“采购管理子系统”、“销售管理子系统”和“库存管理子系统”。
UML实验报告范文
UML实验报告范文实验报告：UML图的设计与应用一、实验目的1. 学习掌握UML（Unified Modeling Language）的基本语法、概念和使用方法；2.了解UML各种图的作用和应用场景；3.进行实际案例的UML建模。
二、实验内容与原理1.UML概述UML是一种面向对象软件开发的标准建模语言，它可以帮助设计师、开发者和用户理解问题领域、设计解决方案并进行沟通。
UML建模图主要有用例图、类图、时序图、活动图、状态图和部署图等，用于描述系统的不同层面。
2.用例图用例图是描述系统功能和参与者之间交互的一种图。
参与者表示与系统交互的角色，用例表示系统的功能需求。
用例图是进行需求分析与系统设计的重要工具之一3.类图类图是描述系统中类以及它们之间关系的一种图。
类图由类、关联、聚合、组合、泛化、实现等元素组成，用于描述系统的静态结构。
4.时序图时序图是描述对象之间消息传递的一种图。
时序图主要用于描述系统中其中一特定操作的交互过程，时序图中的对象称为参与者，他们通过消息进行交互。
5.活动图活动图是描述系统中流程和操作的一种图，用于描述系统中活动的业务流程。
活动图可以展示控制流、对象流和数据流，用于描述系统的动态行为。
6.状态图状态图是描述系统中对象状态变化及其转换的一种图。
状态图展示了对象在不同状态之间的转换过程，用于描述系统的状态机。
7.部署图部署图是描述系统中物理部署和组件之间关系的一种图。
部署图主要用于展示系统的物理结构和系统组件之间的关联情况。
三、实验过程1.确定需求分析并编写用例图根据题目要求和系统需求，确定需求分析，绘制用例图。
用例图主要包括参与者和用例，参与者与用例之间通过关系进行关联。
2.分析系统结构并编写类图根据用例图和系统需求，分析系统结构，识别出系统中的类、接口和关系，绘制类图。
类图包括类、接口、关联、聚合、组合、泛化和实现等元素。
3.分析用户操作流程并绘制时序图根据用例图和系统需求，分析用户操作流程，确定对象的活动顺序，绘制时序图。
软件建模实验报告
软件建模实验报告引言软件建模是指使用计算机辅助工具和技术来构建和描述现实世界的软件系统模型。
实验中，我们将使用一种基于UML的建模工具来实现软件建模，并通过一个具体案例来展示建模的步骤和过程。
实验目的本次实验的主要目的是让学生掌握软件建模的基本概念和方法，能够利用建模工具进行软件建模，并能够根据实际需求进行系统模型的设计和描述。
实验准备在进行实验之前，我们需要准备以下几个方面的内容： 1. 安装建模工具：在本次实验中，我们将使用X建模工具进行软件建模。
请从官方网站下载并安装该工具。
2. 学习建模工具的基本操作：在安装完成后，我们需要学习建模工具的基本操作，包括如何创建新的项目、如何添加类和关系、如何进行模型的导出和保存等。
实验步骤步骤一：需求分析首先，我们需要进行需求分析，明确系统的功能和特性。
在本次实验中，我们以一个图书管理系统为例进行建模。
系统主要包括以下功能：用户注册、图书查询、借阅图书、归还图书等。
步骤二：用例建模在需求分析完成后，我们需要进行用例建模。
用例是对系统功能的一种描述，可以帮助我们理解系统的行为和交互。
根据需求分析，我们可以得到多个用例，如注册用例、图书查询用例等。
在建模工具中，我们可以使用类图来表示用例和参与者之间的关系。
步骤三：类建模类建模是用于描述系统内部结构的一种建模方法。
在本次实验中，我们需要对系统中的各个类进行建模。
首先，可以根据需求分析得到一个初始的类列表，包括用户类、图书类、借还记录类等。
然后，我们可以根据类之间的关系，如继承、关联等，进一步完善类模型。
步骤四：状态建模在一些系统中，状态是非常重要的概念，需要进行专门的建模描述。
在本次实验中，我们可以考虑对图书的状态进行建模，如借出状态、可借状态等。
可以使用状态图来表示状态之间的转换和条件。
步骤五：序列建模序列建模用于描述系统中的交互过程和消息传递。
在本次实验中，我们可以使用序列图来描述用户和系统之间的交互过程。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
UML与软件建模实验报告姓名：孙治民专业：计算机应用1201学号：20127542指导老师：李绘卓目录实验一：用例建模 (3)实验2 分析建模 (6)实验3 设计建模（1） (9)实验4 设计建模（2） (11)用例附件： (13)内容：用例建模、分析建模、设计建模（1）、设计建模（2）实验一：用例建模[ 实验目的] ·掌握客户需求分析的方法和步骤·了解以用例驱动的软件开发方法·识别并编写用例·掌握用Rose 进行用例建模的具体方法和步骤[ 实验内容] 要求学生根据周围的实际情况，自选一个小型应用项目，分析业务需求，识别并编写用例、绘制用例图以理解系统需求。
亦可采用教师指定的“企业综合信息管理系统”中的“进销存管理子系统”[ 实验原理和步骤] 建模原理：(1) 需求获取。
以任务和客户为中心，通过会议、面谈等手段对客户需求进行调研，获得系统目标、范围和功能要求的初步说明。
(2) 用例分析。
确定用例，同时采用分层思想，对用例的层次级别进行划分（高层用例、子系统级、用户目标级）（3）用例描述。
分层绘制用例图，撰写用例的文字描述（采用单栏格式）。
步骤：（1）需求获取。
自选题目，与相关客户、领域专家等反复商讨，获得系统目标、范围和功能要求的初步说明。
（也可采用教师指定的题目：“企业综合信息管理系统”中的“进销存管理子系统”，但要仔细研读“企业现状”、“系统目标、范围和功能要求”等文字说明）。
（2）用例分析。
确定系统范围和边界、确定参与者、确定用例。
（3）用例描述。
分层绘制用例图、描述用例。
画图原理：采用Rose 软件进行用例建模必须建立在完好的系统用例分析基础之上．只有做好系统用例分析，系统用例建模才能这到预期的效果。
步骤：（1）分层绘制用例图，每层采用“包”进行管理。
（2）以“企业综合信息管理系统” -> “进销存管理”子系统-> “销售管理”-> “合同管理” ->“收款单处理”为主线，完成附录2 中的操作过程（亦可选择“企业综合信息管理系统” -> “进销存管理”子系统-> “库存管理” -> “原材料出库” ->“领料单处理”主线）[ 实验结果][ 实验总结] ①各层用例图之间相互关联，对用例图画法和建立要清楚的熟悉操作信息流程，否则很容易搞混；②用例图的画法步骤不是很熟悉，对工具的使用陌生，不能正确的画出和表达用例，缺乏实践。
③了解了各层用例之间的关系，以及用例图的画法，熟悉了工具的使用，对以后的实验帮助很大。
实验2 分析建模[ 实验目的](1) 理解面向对象系统分析和对象类建模(概念建模)的概念(2)了解和掌握面向对象系统分析的方法和步骤(3)了解和掌握寻找待开发系统中类(概念)的方法和技巧(4) 掌握使用ROSE 绘制概念模型的方法[ 实验内容]在用例分析的基础上，选择第一个迭代周期打算开发的用例，建立相关的概念模型。
[ 实验原理和步骤]建模原理：(1)使用概念目录列表（见下图）和非正式分析法（识别出问题域的文本描述中的名词短语，然后将其作为概念或属性的候选对象。
）相结合的方法识别概念。
因此，待开发用例的文字描述中，名词可能成为概念或属性的候选对象；表示行为的动词词组有可能成为事务型或过程型对象；形容词词组有可能对应抽象的名词型概念。
采用的技术基本上就是：ER 图+纯行为+OO 的聚合、泛化。
（2）最终关联的数量介于“需要知道”型关联与【“需要知道”型关联+“需要理解”型（从通用关联列表中派生出的，见下图）】之间。
步骤：（1）识别关键用例作为第一个迭代周期的开发目标（一般是在用例图中被依赖得比较多的用例）。
可以选“企业综合信息管理系统” -> “进销存管理”子系统-> “库存管理” -> “原材料出库” ->“领料单处理”主线中的“领料单处理”用例；也可以选“企业综合信息管理系统” -> “进销存管理”子系统-> “销售管理” -> “合同管理” ->“收款单处理”主线中的“增加销售合同”或“收款单处理”用例。
（其实，选“库存管理”主线更合适；当然，如果要实现产销一体化，以销售订单指导生产和采购，并实现零库存目标，那么一切工作就以销售管理为中心。
即便如此，首选“增加合同”用例也更为合适。
）（2）识别概念和重要属性。
（3）建立概念间的关联。
画图原理：（1）可以采用“逻辑视图”下的类图描述概念模型，只不过每个类中只有类名和属性，没有方法。
在概念建模阶段也没有必要确定属性的类型和访问属性。
（2）概念间的关联可以采用一般关联（无方向实线），当然，对于聚合和泛化，应采用相应的连线（组合：实心菱形+实线；聚合：空心菱形+实线；泛化：空三角形+实线）步骤：（0）前提条件：第一个迭代周期可以选“企业综合信息管理系统” -> “进销存管理”子系统-> “库存管理” ->“原材料出库” ->“领料单处理”主线中的“领料单处理”用例；也可以选“企业综合信息管理系统” ->“进销存管理”子系统-> “销售管理” -> “合同管理” ->“收款单处理”主线中的“增加销售合同”或“收款单处理”用例。
做好与此用例相关的概念模型（1）建立相关的概念模型的基础上，在“逻辑视图”下的类图中描述概念模型，可以直接在类图main 中绘制，也可采用类似用例图中用过的分包机制(2）绘制概念和重要属性。
（3）绘制概念间的关联。
[ 实验结果][ 实验总结]①实验中类图的画法对程序的编制很重要，各类之间的关系对以后程序中的类继承和多态有指导意义；②对类图的不了解，以及不知道如何去辨别分析类与类之间的关系，在者还是开发工具不是很熟悉，缺乏实践动手能力。
③进一步了解UML分析建模的流程和重要性，对以后从事工作有很大帮助，看懂了类图和用例图对以后编程有重要作用。
实验3 设计建模（1）[ 实验目的](1) 理解顺序图的基本概念（2）了解和掌握软件工程中用例逻辑时序的分析方法（3）掌握使用ROSE 创建顺序图的方法[ 实验内容]在用例模型和概念模型的基础上，对首选的用例进行事件分解，识别出系统事件（系统操作），（并写出契约的后置条件）；为每个系统事件画顺序图，为对象分配职责。
[ 实验原理和步骤]原理：(1) 在系统顺序图中，所有的系统都被当成黑盒子看待，顺序图的重点是参与者发起的跨越系统边界的事件。
(2) 系统事件是由某参与者发起的指向系统的输入事件。
一个事件的发生能够触发一个响应操作的执行。
(3) 请仔细研究下图,考察它是如何从左边的"购买商品"用例的文字描述中分解出3 个系统事件的。
（4）参照用例模型和概念模型，为每个系统操作估计后置条件。
（实例创建、形成关联、属性修改）（5）按照设计模式为对象分配职责。
步骤：（1）分析首选用例的文字描述，按事件进行分解，识别出系统事件。
（下面以“企业综合信息管理系统” -> “进销存管理”子系统-> “销售管理” -> “合同管理” ->“收款单处理”主线中的“收款单处理”用例为例）。
我们暂不考虑批处理。
第一个核对，因为要将“货款金额填写到合同中”。
后置条件显然有“销售合同”的属性修改。
此合同显然已经存在，不需要创建，但需要根据合同编号find，然后形成关联。
第二个核对需要根据合同明细到仓库的“存货明细”（概念模型中还没有）中去查。
此核对发生前虽然敲了一下键盘，但随后并没有新的消息穿越系统边界，因此这仍然是同一个系统事件。
先考虑成功场景，应该向库存系统发提货单（概念模型中还没有）就结束了。
后续的削减库存（核销）、预警显然不是销售管理员的职权，并且真正的核销必须由仓库的发货人执行，才能保证货帐一致。
并且“生产厂家”与“邮购公司”的运作方式不同，后者是自己的员工取货并邮寄，而前者还有可能是来人来车取货，这时仓库收到取货单后并不能立即自动处理（开发货单），必须等取货人到达才能处理。
根据题意，本项目应该是“生产厂家”模式。
这又存在一个问题，如果在开出提货单后不修改库存，可能影响并发用户和后续付款单的处理。
所以有必要设计一个“临时存货明细”（概念模型中还没有）（不是真实的“存货明细”）供修改，何时按存货明细”进行刷新应该是库存管理系统的事（比如每天夜里刷新，但因为雨雪天气，取货人迟迟不提货，是提货单作废（相当于退回销售系统，付款单变为未处理）还是就强行刷新（此时有冲突危险）？）失败场景。
向“生产调度部门”发送“产品生产申请单”。
如果是专门为此单进行生产，那么还应该有库存系统发来的“产品入库通知处理”用例来调用本用例进行发货。
本题显然一概根据付款单运作，因此如果失败，就不处理付款单，但按日期把它排在待处理付款单的前面。
从前面的分析来看，就一个系统事件，我们就命名为“付款单处理(pb:付款单)”（2）为每个系统事件估计后置条件。
(以上已做了部分分析)（3）按设计模式进行设计。
首先考虑控制者,领域控制者选参与者角色，即“销售人员”。
为了避免使用FORM,窗口等表示层对象,我们人造一个类”应用协调者”向控制者发送消息。
[ 实验结果][ 实验总结]①对重点实验结果进行分析，了解顺序图的创建步骤和方法，并结合案例，分析事件的发生时序，使人一目了然；②实验中的问题和提高：对自己的分析或设计进行评价，指出合理和不足之处，提出改进的方案。
③收获与体会：学会了顺序图的创建方法，重点是其中事件发生的时序顺序，清楚表达用例。
实验4 设计建模（2）[ 实验目的](1)理解面向对象类之间关联关系的概念(2)了解和掌握分析类之间的关联关系的方法(3)了解和掌握待开发系统中类之间关联关系的分析方法(4)完善设计类图，掌握使用ROSE 对关联进行建模的过程[ 实验内容]根据设计建模（1）中的交互分析，进一步设计关联和对象可见性（补上遗漏的关联）,完善设计类图。
[ 实验原理和步骤]建模原理：（1）关联关系描绘了给定类的对象个体之间的语义连接，是类与类之间的连接。
关联可以分为一般关联、聚合关联、组合关联和依赖关联等。
（2）一般关联包括一对类的二元关联及多个类之间的多元关联。
（3）聚合(Aggregation)表示整体和部分之间较强的关联关系，聚合关系的多重性大于1，则称为共享聚合。
（4）组合(Composition)关系表示整体和部分之间有比聚合关系更强的关系，它们之间是一对一的关系，即同生死共存亡，组合关系不能共享。
（5）依赖关系是一种使用关系，表现为一个对象仅仅调用了另一个对象的服务。
可以使用下列的指导方针列出暂时性的关系：(1)存在两个或两个以上的类相互之间就可能有关联。