实验指导书(UML).doc

UML实验指导书统一建模语言实 验 指 导 书软件学院软件工程系李林林2009年3月目 次实验一 rose的使用3实验二 用例图4实验三 类图、对象图7实验四 序列图与协作图8实验五 状态图12实验六 活动图14实验七 包图、构件图和部署图15实验八 运用UML进行系统分析与设计图书管理系统的分析与设计1624实验一 rose的使用【实验题目】：rose的使用【实验目的】：熟悉rose的环境，掌握rose的基本使用方法【实验内容】：（1）熟悉rose界面的5大部分：浏览器、文档窗口、工具栏、框图窗口和日志；界面的五大部分是浏览器、文档窗口、工具栏、框图窗口和日志。它们的作用如下： 浏览器：用于在模型中迅速浏览，屏幕左边的树型视图利用浏览器，可以：a) 增加模型元素b) 浏览现有模型元素c) 浏览现有模型元素之间的关系d) 移动模型元素e) 更名模型元素f) 将模型元素加进框图g) 将文件或URL链接到元素h) 将元素组成包i) 访问元素的详细规范j) 打开框图（2）使用rose创建模型，保存模型，导出与导入模型，向Web发表模型；保存模型的方法： file-save导出与导入模型 导出模型的方法： file-export model导出类包的方法： file-export 导出类的方法： file-export 导入模型、包或类的方法： file-import model 选择要导入的文件名，可选文件类型：模型（.mdl）、petal(.ptl)。类别(.cat)、子系统(.sub)将模型发表到web的方法: tools-web publisher实验二 用例图【实验题目】：用例图【实验目的】：熟悉和掌握用例图的相关概念，使用用例图进行功能分析【实验内容】：（1）学习使用Rational Rose增加系统用例模型、用例图、用例与角色的方法a) 右单击浏览器中的use case视图包并选择new-packageb) 将新包命名为system use case modelc) 右单击system use case model包并选择new-use case diagramd) 将新图命名为maine) 双击浏览器中的main use case 图打开图f) 用用例工具栏按钮将新用例加进图中并为新用例命名g) 用角色工具栏按钮将新角色加进图中并为新角色命名重复第f步、第g步直到所有的用例、参与者建立完毕；增加关联a) 用unidirectional association 工具栏按钮在参与者与用例之间画出关联；b) 按上述步骤将其余关联加进图中；增加用例描述：选中用例在文档窗口来创建用例描述；增加角色描述：选中参与者在文档窗口来创建参与者描述；（2）通过对“学生信息管理系统”的需求描述，确定系统用例图：“学生信息管理系统”的需求描述如下：u 在每个新学年开始都会有新生入学，这时系统的管理人员可以通过系统将这些新生的学籍、年龄、家庭住址、性别、身高、学生证号、身份证号等基本信息存入数据库，每个新生都对应一个唯一的编号，此编号可以是学生证号，在日程管理中，系统管理员还可以对所有学生的基本信息进行查询、修改和删除等操作，校领导可以查询、修改全校所有学生的基本信息，教师可以在日常工作中查询、修改自己办理学生的基本信息。u 学校领导可以通过本系统了解每个班的任课教师、辅导员、学生姓名、学生人数、专业等班级基本信息。系统管理员可以进行查询班级基本信息、添加班级、修改班级基本信息、删除班级等操作。u 在考试结束以后，教师可以将学生的考试成绩录入系统，还可以对学生的成绩进行查询和修改。学生可以通过本系统进行成绩的查询。u 学生还可以在网上选择自己选修的课程（必修课必须上，所以不用选），学生通过本系统可以看到有哪些课程可以选以及课程的基本信息。课程的基本信息包括：课程号、所属专业、课程名称、开课学期、学时数、学分、任课教师等。每个学生每学期的选修课程数不得大于6门，如果已经选择了6门课程则不能再选择其他课程。只有将已选择的课程删除掉才能再选择新课程。系统管理员负责修改、增加、删除选修课程。u 每个用户登录系统，都需要一个账号，这需要系统管理员对账号进行管理。按照业务模块视角绘制用例图：试采用业务主角视角对系统建立用例图。实验三 类图、对象图【实验题目】：类图、对象图【实验目的】：熟悉和掌握类图和对象图的相关概念，使用类图进行领域分析【实验内容】：（1）使用Rational Rose建立类图和对象图方法和步骤；（2）通过对“学生信息管理系统”的需求描述，确定系统类图：“学生信息管理系统”的需求描述如下：u 在每个新学年开始都会有新生入学，这时系统的管理人员可以通过系统将这些新生的学籍、年龄、家庭住址、性别、身高、学生证号、身份证号等基本信息存入数据库，每个新生都对应一个唯一的编号，此编号可以是学生证号，在日程管理中，系统管理员还可以对所有学生的基本信息进行查询、修改和删除等操作，校领导可以查询、修改全校所有学生的基本信息，教师可以在日常工作中查询、修改自己办理学生的基本信息。u 学校领导可以通过本系统了解每个班的任课教师、辅导员、学生姓名、学生人数、专业等班级基本信息。系统管理员可以进行查询班级基本信息、添加班级、修改班级基本信息、删除班级等操作。u 在考试结束以后，教师可以将学生的考试成绩录入系统，还可以对学生的成绩进行查询和修改。学生可以通过本系统进行成绩的查询。u 学生还可以在网上选择自己选修的课程（必修课必须上，所以不用选），学生通过本系统可以看到有哪些课程可以选以及课程的基本信息。课程的基本信息包括：课程号、所属专业、课程名称、开课学期、学时数、学分、任课教师等。每个学生每学期的选修课程数不得大于6门，如果已经选择了6门课程则不能再选择其他课程。只有将已选择的课程删除掉才能再选择新课程。系统管理员负责修改、增加、删除选修课程。每个用户登录系统，都需要一个账号，这需要系统管理员对账号进行管理。实验四 序列图与协作图【实验题目】：序列图与协作图【实验目的】：熟悉和掌握序列图与协作图的相关概念，使用序列图与协作图对系统进行建模。【实验内容】：（1）使用Rational Rose建立序列图与协作图方法和步骤；（2）对如下交互序列用序列图进行描述： 李老师希望通过系统查询到某名学生的学科成绩信息； 李老师通过用户界面录入学生的学号； 用户界面根据学生的学号向数据库访问层请求学生信息； 数据库访问层根据学生的学号加载学生信息； 数据库访问层根据学生信息和学科科目获取该名学生的分数信息； 数据库访问层将学生信息和分数信息提供给用户界面； 用户界面将学生信息和分数信息显示出来；（3）对如下备选过程采用顺序图进行描述：该名学生没有学科成绩：数据库访问层返回学科成绩为空，系统提示李老师没有该学生的成绩；系统没有该学生的信息：数据库访问层返回学生信息为空，系统提示李老师学生不存在。（4）试将（2）、（3）转换为协作图描述交互过程，并体会协作图与顺序图的异同。实验五 状态图【实验题目】：状态图【实验目的】：熟悉和掌握状态图的相关概念，使用状态图对系统进行建模。【实验内容】：（1）使用Rational Rose建立状态图方法和步骤；（2）试对学生信息管理系统中学生账号的状态进行分析：对于学生账号来说，当有新的同学入学时，将会给新生创建一个新的账号，以后该生可以使用这个账号去选课，一般来说，每个人的选课数量不能超过6门，如果已经选了6门就不能再进行选课了，但是学生可以将原来的选课信息删除再进行选课。若学生毕业，需要将其账号删除。（3）试对图书馆管理系统中书的状态进行分析；实验六 活动图【实验题目】：活动图【实验目的】：熟悉和掌握活动图的相关概念，使用活动图对系统进行建模。【实验内容】：（1）使用Rational Rose建立活动图方法和步骤；（2）试对学生信息管理系统中教师参看、修改学生信息的活动进行描述；实验七 包图、构件图和部署图【实验题目】：包图、构件图和部署图【实验目的】：熟悉和掌握包图、构件图和部署图的相关概念，使用包图、构件图和部署图对系统进行建模。【实验内容】：（1） 使用Rational Rose建立包图、构件图和部署图方法和步骤；（2） 试采用MVC架构对学生信息管理系统进行包的划分；（3） 试对 “教师查看学生成绩”用例设计其构件图；（4） 使用B/S结构对学生信息管理系统设计其部署图；实验八 运用UML进行系统分析与设计图书管理系统的分析与设计【实验题目】：运用UML进行系统分析与设计图书管理系统的分析与设计【实验目的】：熟悉和掌握使用软件工程开发工具进行软件系统的分析与设计【实验内容】：运用UML进行系统分析与设计图书管理系统的分析与设计一 概述UML（Unified Modeling Language）：用于确定、展示、记录挼建系统的整个开发过程。用例图：对系统的功能进行分析，描述系统的功能性要求；类图：展示系统的结构；活动图：描述为了完成某个目标需要做的活动以及这些活动的执行顺序，多用于对系统的工作流程建模；顺序图：用来描述对象之间的交互序列及其发生顺序。顺序图可以用来描述一个用例的实现，即说明对象如何通过交互来执行用例的行为。通过一个或多个顺序图来描述实现用例的实现过程（对象交互过程）。用例结构中，主事件流将有一个顺序图，而每个独立的用例分支流（扩充用例和包含用例）都分别有一个顺序图。协作图：交互的语境与参与交互的对象的相互关系和整体组织。状态图：用于展示一个对象在其生命周期中各个时期的状态及其变化规律图形。用于捕获系统动态行为。构件图：描述系统物理实现方面的信息。部署图：描述系统的构件在节点上的部署和运行情况。二 图书管理系统实例2.1需求部分用例（1）需求获取从系统的最终用户（读者、图书管理员）方获取系统的要求和规范： 图书馆应用程序应当是图书馆的支持系统。 图书馆把书籍和杂志借给借书者（读者）的条件是读者应当在该系统中注册过，同样书籍和杂志也应当在系统中注册过。 图书馆处理购买新书或杂志的操作，畅销书或杂志应当多购几本，旧的书籍和杂志当它们过时或残破时就应适当把它们从书架上请下来。 图书管理员是图书馆中的职员，他的职责就是与顾客 (借书者）打交道并通过该系统完成工作。 借书者可以预借一本当前不在图书馆中的书籍或杂志，当这本书被归还或被购入图书馆的时候，他就会接到通知；当借书者借到这本书或杂志的时候，预定就会被取消；也可以使用显示程序取消预借。 图书馆可以很容易地创建，更新和删除系统中的书名，借书者，借阅情况以及预借情况等信息 该系统可以运行于所有流行的操作系统，包括 UNIX， Windows以及 OS/2，它还应当有先进的友好的图形用户界面 ( GUI )。 该系统应当很容易使用新的功能扩展。 在本案例分析中，该系统的第一个版本不需要处理某个读者预借的书籍成为可借书籍时发送消息给读者的操作，也不需要检查某本书籍是否已经超时了。 （2）需求描述：往往采用用例描述来进行，其中的关键用例可以结合活动图来描述其事件流。例如借书用例的事件流可以表述如下：（3）需求分析：分析的目的是为了获得和描述系统中所有的要求，以及生成一个在该系统中定义关键域类的模型。其目标是在开发者与制定要求的人之间建立相互理解和沟通，因此分析是一种典型的与用户或客户合作的行为。在这个阶段开发者不应该考虑具体的代码或程序细节；这只是真正地理解要求和正在设计的系统的实际情况的第一步。分析的第一步应当是判断该系统将被用于做什么以及谁将使用它。这分别是所谓的用例（use case）和参与者（actor）。用例描述了图书馆系统具体应当提供哪些功能，即系统的功能要求。一个用例分析过程包括阅读和分析规范，并且讨论该系统的潜在的用户 (客户)。图书馆中的参与者是图书管理员和借书者，图书管理员是该系统的用户而借书者则是顾客，查看并且预订书籍和杂志的人应该是借书者，但是有时候也可能是一个图书管理员或另外一个图书馆。（4）需求验证：与客户和领域专家进行沟通和交流，反复验证用例模型的准确性；2.2设计部分（1）问题域分析分析过程中还要详细地列举讨论域 (domain ，系统中关键的类 )，为了进行讨论域分析，需要充分理解规范和用例并且着眼于系统将要处理的 概念 ； 或者与使用者及讨论域专家组织一次集体研讨会谈，尝试找出所有必须处理的关键概念以及它们之间的相互关系。图书馆系统中的讨论域类如下：: BorrowerInformation（这样命名是为了区别于用例图表中的参与者 Borrower）， Title， Book Title， Magazine， Item， Reservation和 Loan。 下图是一张类图，标出它们的相互关系。这些讨论域类是用户自定义的类，指定该类的对象是关键域的一部分并将被持久的保存在系统中。可以对复杂的对象进行状态分析，建立状态图：类的状态图，说明了可能的状态以及需要被处理的过渡期 (以及触发该过渡期的操作 )。（2）行为建模（顺序图、协作图）类的对象中包含的行为图 (序列图、协作图）：说明类的一个具体的方