可视化建模与UMLI项目指导书

1、可视化建模与UML I课程项目指导书软件工程系一：完成自拟项目的需求分析（一）基本信息本次实践是自拟项目（三级项目）。对自拟项目进行需求分析，构建用例模型解决该问题。1、类型： 综合类 设计类 创新类 验证类2、学时安排：课上2学时。3、教学目标：（1）理解用例模型对需求建模的重要性；（2）识记构建用例图的方法，并能够熟练运用用例图完成对系统的需求分析。（3）识记书写用例描述的关键点，完成对每个用例的分析和描述。（二）组织形式课上完成本次实践的内容，采取分小组的方式，每组35人，包括1名组长。由组长负责分配工作。（三）任务描述每个小组自拟题目，完成该项目的需求分析，要求使用工具StarUML完

2、成系统的总体用例图，并且对于关键用例要给出对应的用例描述。（三）指导内容1、相关知识：（1）用例图 识别参与者：参与者（也可以称为角色，Actor）是系统外部的一个人或者物，它以某种方式参与了系统的执行过程。参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。参与者之间也可以象类一样存在泛化关系。用例：用例是代表系统中各个项目相关人员之间根据系统的行为所达成的契约。用例描述了在不同条件下，针对某一项目相关人员的请求，系统对其作出的响应。用来描述参与者可以感受到的系统服务或功能。用例和用例之间的关系：用例除了与参与者

3、有关联关系外，用例之间也存在着一定的关系，如泛化关系、包含关系、扩展关系等。例1：例2：（2）用例描述用例描述的组成部分：用例标识用例名称涉及的参与者用例概述前置条件（Preconditions）后置条件（Postconditions）事件流（Flow of events）基本流程，不考虑异常；分支流程（Subflows）例1：用例标识UC1用例名称上传课件参与者教师前置条件确认教师身份后置条件系统增加了新的课件信息用例概述教师将该课程的课件上传到服务器上。基本事件流参与者动作系统动作1.教师确认要上传的课件信息。2.系统检查该课件信息的有效性。3.系统从本地提取课件到服务器。4.系统将课件信

4、息保存到相应位置，并提示保存成功。备选事件流2.a 如果课件格式不符合要求，系统提示此信息，并返回到步骤1.3.a 如果提取信息失败，提示此信息，返回到步骤1.4.a 如果保存信息失败，提示此信息，返回到步骤1.备注服务器将记录每次上传的时间。（3）其他知识资源详细内容请参见第4章 用例与用例图的PPT或者 教材P51-P68 。2、过程与步骤：第一步：分析项目需求，识别出参与者。第二步：分析系统功能，识别出用例。第三步：分析参与者之间的关系。第四步：分析用例之间的关系。第五步：绘制整体用例图的草图。第六步：优化并调整用例图。第七步：采用工具StarUML画出系统的用例图，具体过程 Use C

5、ase Modeladd Usecase Diagram，创建参与者actor和用例usecase。完成之后将用例图粘贴到需求报告中。第八步：对用例进行优先级排序。第九步：对优先级高的用例完成用例的详细描述。（四）成果提交组长将该小组的项目内容汇总到一个word文档中，形成一份完成的需求报告。小组成员每人提交一份该完整的需求报告，注明提交人的姓名、学号和任务分工。需求报告中必须包含系统总体用例图和核心用例的用例描述，其余部分可以适当增加，比如项目概述等。（五）考核方式与标准1、考核方法（1）评阅项目报告；（2）课堂检查小组项目的完成情况。2、考核标准本次实践占形成性考核成绩中的10分。标准：能

6、根据系统的概述完成系统的整体用例图，并对核心用例能够进行详细描述。成绩构成：小组得分+个人得分。小组得分共5分。（1）任务分工合理，小组合作默契，系统选题新颖、分析透彻，给4-5分。（2）部分同学参与度低，小组合作欠佳，选题普遍，分析不够透彻，给2-3分。（3）主要工作全由组长一人完成，小组合作极差，选题陈旧，分析停留在表面，给0-1分。个人得分共5分。根据需求报告中小组成员的任务完成情况，给与适当的分数。（1）用例图中参与者和用例的识别全面、正确，命名规范，关系正确；用例描述详细、流程正确，给4-5分。（2）用例图中参与者或用例识别不够全面、正确，或者命名不符合规范，或者部分关系不正确；用例

7、描述，不够详细，缺少关键流程，给2-3分。（3）用例图中缺少关键参与者或者关键用例，参与者和用例命名随意，不符合规范，用例间关系不正确；用例描述流于页面，没有深入系统内部，或者没有给出分支流程的描述，给0-1分。说明：如附加其他部分，可以酌情加分。二：完成自拟项目的设计报告（一）（一）基本信息本次实践是自拟项目（三级项目）。对自拟项目进行系统设计，构建系统的顺序图和分析类图。1、类型： 综合类 设计类 创新类 验证类2、学时安排：课上2学时。3、教学目标：（1）理解顺序图和分析类图对设计建模的重要性；（2）识记构建顺序图的方法，并能够熟练运用顺序图来完成系统的对象设计。（3）识记构建分析类图的

8、方法，并能够熟练的构建系统的类图。（二）组织形式课上完成本次实践的内容，采取分小组的方式，每组35人，包括1名组长。由组长负责分配工作。（三）任务描述每个小组根据上次实践课自拟项目的需求分析报告，完成该项目的系统设计（一）报告，要求使用工具StarUML完成该系统的顺序图和分析类图建模。（三）指导内容1、相关知识：（1）顺序图 顺序图（Sequence Diagram） 顺序图：强调消息的时间顺序的交互图。图形上是一张表，对象沿X轴排列，消息沿Y轴按时间顺序排列。顺序图描述了对象之间传送消息的时间顺序，它用来表示用例中的行为顺序。三类对象：边界对象、实体对象、控制对象。 状态图中的基本概念：O

9、bject (包括actor实例)、Lifeline (生命线)、Focus of control(控制焦点)、activation(激活期)、Message(消息)。 例1、查询书籍用例对象的顺序图。 （2）分析类图 分析类图（Class Diagram） 类图：构建分析类图，完成系统内部类的初步设计。类是对一组具有相同属性、操作、关系和语义的对象的抽象。类图是用来显示系统中的类、接口以及它们之间的静态结构和关系的一种静态模型，它用于描述系统的结构。类图的建模贯穿系统的分析和设计阶段的始终。类图中的基本概念：名称部分（Name）、属性部分（Attribute）和操作部分（Operation）

10、。类之间的关系：是指事物之间的联系。在面向对象的建模中，类之间最常见的关系有：依赖关系、泛化关系、关联关系和实现关系。 例1、查询图书用例对象顺序图对应的分析类图。 （3）其他知识资源详细内容请参见第5章 类图和对象图的PPT或者 教材P69-P92，第6章 顺序图和通信图的PPT或者 教材P93-P115 。2、过程与步骤：第一步：根据需求分析报告中，高优先级用例的用例描述，识别出每个用例中的三类对象。第二步：识别出三类对象间传递的关键消息。第三步：绘制每个用例描述的顺序图草图。第四步：修改顺序图草图。第五步：采用工具StarUML画出每个用例的顺序图，具体过程“双击” Analysis M

11、odelmain，创建三类对象：Entity、Boundary、Controller，并完成每类对象的命名。第六步：创建顺序图 Analysis Modeladd SequenceDiagram，将上一步已经创建好的三类对象拖拽到顺序图中。将三类对象的显示方式改为图像方式：Ctrl+A，Ctrl+Shift+I。完成对象间消息的传递，注意返回消息修改右下角“General属性框中的ActionKind属性，改为return消息即可”。完成之后将顺序图粘贴到设计报告一中。第六步：分析并识别该顺序图中关键类。第七步：识别每个类中的属性和方法，并设置属性和方法的可见性。第八步：绘制每个分析类图的草图

12、。第九步：修改分析类图。第十步：采用工具StarUML该顺序图的分析类图，具体过程 Design Modeladd Class Diagram，创建类class。完成之后将分析类图粘贴到设计报告一中。（四）成果提交组长将该小组的项目内容汇总到一个word文档中，形成一份完成的设计报告一。小组成员每人提交一份该完整的设计报告一，注明提交人的姓名、学号和任务分工。设计报告一中必须包含系统中高优先级用例的顺序图和该用例对应的分析类图，其余部分可以适当增加，比如界面设计等。（五）考核方式与标准1、考核方法（1）评阅项目报告；（2）课堂检查小组项目的完成情况。2、考核标准本次实践占形成性考核成绩中的10

13、分。标准：能分析出高优先级用例的用例描述中的三类对象和消息，完成该用例的顺序图，给出该用例对应的分析类图。成绩构成：小组得分+个人得分。小组得分共5分。（1）任务分工合理，小组合作默契，全组顺序图的风格一致且全部正确，给4-5分。（2）部分同学参与度低，小组合作欠佳，小组内顺序图的风格不一致，部分顺序图不正确，给2-3分。（3）主要工作全由组长一人完成，小组合作极差，小组内顺序图的风格迥异，基本全部错误，给0-1分。个人得分共5分。根据设计报告二中小组成员的任务完成情况，给与适当的分数。（1）顺序图中三类对象和关键消息识别正确，消息传递符合规范，图形符号正确；分析类图中类抽取正确，属性和方法设

14、置合理，类间关系设置正确，图形符号正确，给4-5分。（2）顺序图中三类对象和关键消息识别部分错误，消息传递基本符合规范，图形符号基本正确；分析类图中类抽取基本正确，属性和方法设置部分不合理，类间关系设置基本正确，图形符号基本正确，给2-3分。（3）顺序图中三类对象和关键消息识别存在错误，消息传递不合理，图形符号错误；分析类图中类抽取存在错误，属性和方法设置不合理，类间关系设置不正确，图形符号不正确，给0-1分。说明：如附加其他部分，可以酌情加分。三：完成自拟项目的设计报告（二）（一）基本信息本次实践是自拟项目（三级项目）。对自拟项目进行系统设计，构建系统的状态图和活动图。1、类型： 综合类 设

15、计类 创新类 验证类2、学时安排：课上2学时。3、教学目标：（1）理解状态图和活动图设计建模的重要性；（2）识记构建状态图的方法，并能够熟练运用状态图完成对某个对象的状态分析与设计。（3）识记构建活动图的方法，并能够熟练运用活动图完成对某个工作流程的分析与设计。（二）组织形式课上完成本次实践的内容，采取分小组的方式，每组35人，包括1名组长。由组长负责分配工作。（三）任务描述每个小组根据上次实践课自拟项目的系统设计（一）报告，完成该项目的系统设计（二）报告，要求使用工具StarUML完成该系统的状态图和活动图建模。（三）指导内容1、相关知识：（1）状态图 状态图（Statechart Diag

16、ram） 主要用于描述一个对象在其生存期间的动态行为，表现为一个对象所经历的状态序列，引起状态转移的事件（Event），以及因状态转移而伴随的动作（Action）。状态图只为单个对象模型。当所建模的类呈现出值得关注的和复杂的动态行为时，状态图才是有价值的。 状态图中的基本概念：State (状态)、Action (动作)、Transition (转移)、Event (事件)。 例1、电脑状态图。 例2、借书证状态图。 （2）活动图 活动图（Activity Diagram） 活动图被设计用于简化描述一个过程或者操作的工作步骤。活动图对表示并发行为很有用。活动图的应用非常广泛，包括：1. 对系统

17、的工作流(workflow)建模，即对系统的业务过程建模。2. 对具体的操作建模，描述计算过程的细节。活动图中的基本概念：activity (活动)、transition (转移)、swimlane (泳道)、branch (分支)、fork and join (分叉和汇合)、object flow (对象流)。 例1、一个咨询公司会见一个客户时的业务过程。 （3）其他知识资源详细内容请参见第7章 状态机图和活动图的PPT或者 教材P117-P136 。2、过程与步骤：第一步：分析并识别系统中具有复杂状态的对象。第二步：分析并确认每个对象的状态。第三步：绘制每个对象的状态图草图。第四步：修改状

18、态图草图。第五步：采用工具StarUML画出每个对象的状态图，具体过程 Design Modeladd Statechart Diagram，创建状态state。完成之后将状态图粘贴到设计报告二中。第六步：分析并识别系统中的工作流程。第七步：分析并确认每个工作流程中涉及到的活动和活动之间的关系。第八步：绘制每个活动图的草图。第九步：修改活动图。第十步：采用工具StarUML画出每个工作流程的活动图，具体过程Design Modeladd Activity Diagram，创建活动activity。完成之后将活动图粘贴到设计报告二中。（四）成果提交组长将该小组的项目内容汇总到一个word文档中，形成一份完成的设计报告二。小组成员每人提交一份该完整的设计报告二，注明提交人的姓名、学号和任务分工。设计报告二中