uml复习整理汇总.docx

uml复习整理汇总.docx

《uml复习整理汇总.docx》由会员分享，可在线阅读，更多相关《uml复习整理汇总.docx（24页珍藏版）》请在冰豆网上搜索。

uml复习整理汇总

UML复习汇总

一根据有关销售点系统的需要创建一个用例图，要求途中使用英文名称（不用写出扩展点）

（1）系统允许管理员（adminisrator）通过从磁盘加载存货数据（loadinventorydata）来运行存货清单报告（runinventoryreports）

（2）管理员通过从磁盘加载存货数据，向磁盘保存存货数据（saveinventorydata）来更新存货清单（updatainventory）

（3）销售员（salesclerk）记录正常的报告（walk-in-sale）

（4）电话操作员（telephoneoperator）是处理电话订单（phoneorder）的特殊销售员

（5）任何类型的交易都需要更新存货清单

（6）如果交易使用信用卡，那么销售员需要核实信用卡（verity-creditcard）

（7）如果交易使用支票，那么销售员需要核实支票（veritycheck）

请根据上述确定参与者、用例并绘制用例图。

1、确定参与者：

2、确定用例：

3、绘制用例图：

二、聚合关系和组合关系的区别：

（1）聚合关系：

是一种特殊类型的关联，表示整体与部分关系的关联，部分可能属于多个整体。

描述了“hasa”的关系。

（2）组合关系：

是聚合关系中的一种特殊情况，是更强形式的聚合，又称强聚合。

成员对象的生命周期取决于聚合的生命周期。

组合不仅控制着成员对象的行为，而且控制着成员对象的创建和解构。

（3）组合和聚合都是整体类和部分类之间的整体和部分关联，在聚合中，部分可才能属于多个整体，在组合中，部分只能属于一个整体。

1.聚合关系是“has-a”关系，聚合的整体与部分间关系较弱,

其代表部分的对象与代表整体的对象生存期无关,删除了代表整体的对象不一定会删除代表部分的对象.

2.组合关系是“contains-a”关系,组合的整体与部分间关系较强,

其代表部分的对象与代表整体的对象具体相同的生存期,当删除代表整体的对象,同时也会删除了代表部分的对象.

•聚合与组合示例

大雁群里每一只大雁都有自己的雁群,每个雁群都有好多大雁,大雁不会因为它们的群主将雁群解散而无法生存,大雁与雁群的关系就可以称之为聚合

每只大雁都有两只翅膀,而当大雁挂了雁翅也就不能单独生存了,大雁与雁翅的关系就叫做组合

三、顺序图和协作图的区别：

（1）顺序图：

强调交互的时间和顺序，缺点是占地面积大，即按照时间布局；

（2）协作图：

强调交互的语境和交互对象的整体组织结构，即按照空间组织布局；

四、用例的特点：

（1）相对独立和完整

（2）由参与者启动

（3）有明确的回报要求

（4）定义形式为动宾形式

五、区分用例之间的关系

用例的组成：

用例、参与者、参与者和用例之间的关系

六、

（1）区分动态图和静态图

动态图：

协作图、时序图、活动图、状态图、对象图

静态图：

类图、用例图

模型管理：

包图

（2）包含，泛化和拓展之间的关系

共性：

都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

1、包含（include）

包含关系：

使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。

基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。

基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。

包含关系对典型的应用就是复用，也就是定义中说的情景。

但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。

这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。

例如：

业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。

这时包含关系可以用来理清关系。

2、扩展（extend）

扩展关系：

将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（ExtensionPoint）上进行扩展，从而使基用例行为更简练和目标更集中。

扩展用例为基用例添加新的行为。

扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。

但是扩展用例对基用例不可见。

对于一个扩展用例，可以在基用例上有几个扩展点。

例如，系统中允许用户对查询的结果进行导出、打印。

对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。

导入、打印和查询相对独立，而且为查询添加了新行为。

因此可以采用扩展关系来描述：

4、泛化（generalization）

泛化关系：

子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。

子用例可以使用父用例的一段行为，也可以重载它。

父用例通常是抽象的。

在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。

例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示：

转：

UML中扩展和泛化的区别

泛化表示类似于OO术语“继承”或“多态”。

UML中的UseCase泛化过程是将不同UseCase之间的可合并部分抽象成独立的父UseCase，并将不可合并部分单独成各自的子UseCase；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。

如下：

●泛化侧重表示子用例间的互斥性；

●包含侧重表示被包含用例对Actor提供服务的间接性；

●扩展侧重表示扩展用例的触发不定性；详述如下：

既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况：

⒈无条件发生：

肯定发生的；

⒉有条件发生：

未必发生，发生与否取决于系统状态；

因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。

进一步，用例的存在是为Actor提供服务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。

同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。

另外一点需要提及的是：

泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。

七、汽车和自行车都是交通工具。

假设一个交通工具只能归一个人所有，一个人可能没有自行车或者是汽车，也可能拥有多辆自行车或者汽车。

人又划分为男人，女人两类，每个人都拥有身份证号、姓名、职业、工作单位、地址、电话号码、出生日期等属性。

汽车和自行车也都有商标、颜色、型号、制造厂商等属性，汽车同时又必须拥有一个车牌号。

特别地，每辆汽车都只有两个前灯和一台发动机。

请根据上述叙述绘制一张类图。

要求：

给出所有类、类的属性和类之间的关系。

八、通过对“学生信息管理系统”的需求描述，确定系统用例图：

“学生信息管理系统”的需求描述如下：

◆在每个新学年开始都会有新生入学，这时系统的管理人员可以通过系统将这些新生的学籍、年龄、家庭住址、性别、身高、学生证号、身份证号等基本信息存入数据库，每个新生都对应一个唯一的编号，此编号可以是学生证号，在日程管理中，系统管理员还可以对所有学生的基本信息进行查询、修改和删除等操作，校领导可以查询、修改全校所有学生的基本信息，教师可以在日常工作中查询、修改自己办理学生的基本信息。

◆学校领导可以通过本系统了解每个班的任课教师、辅导员、学生姓名、学生人数、专业等班级基本信息。

系统管理员可以进行查询班级基本信息、添加班级、修改班级基本信息、删除班级等操作。

◆在考试结束以后，教师可以将学生的考试成绩录入系统，还可以对学生的成绩进行查询和修改。

学生可以通过本系统进行成绩的查询。

◆学生还可以在网上选择自己选修的课程（必修课必须上，所以不用选），学生通过本系统可以看到有哪些课程可以选以及课程的基本信息。

课程的基本信息包括：

课程号、所属专业、课程名称、开课学期、学时数、学分、任课教师等。

每个学生每学期的选修课程数不得大于6门，如果已经选择了6门课程则不能再选择其他课程。

只有将已选择的课程删除掉才能再选择新课程。

系统管理员负责修改、增加、删除选修课程。

◆每个用户登录系统，都需要一个账号，这需要系统管理员对账号进行管理。

九、使用RationalRose建立序列图与协作图方法和步骤；

（2）对如下交互序列用序列图进行描述：

1李老师希望通过系统查询到某名学生的学科成绩信息；

2李老师通过用户界面录入学生的学号；

3用户界面根据学生的学号向数据库访问层请求学生信息；

4数据库访问层根据学生的学号加载学生信息；

5数据库访问层根据学生信息和学科科目获取该名学生的分数信息；

6数据库访问层将学生信息和分数信息提供给用户界面；

7用户界面将学生信息和分数信息显示出来；

（3）对如下备选过程采用顺序图进行描述：

该名学生没有学科成绩：

数据库访问层返回学科成绩为空，系统提示李老师没有该学生的成绩；

系统没有该学生的信息：

数据库访问层返回学生信息为空，系统提示李老师学生不存在。

（4）试将

（2）、（3）转换为协作图描述交互过程，并体会协作图与顺序图的异同。

十、使用RationalRose建立状态图方法和步骤；

（2）试对学生信息管理系统中学生账号的状态进行分析：

对于学生账号来说，当有新的同学入学时，将会给新生创建一个新的账号，以后该生可以使用这个账号去选课，一般来说，每个人的选课数量不能超过6门，如果已经选了6门就不能再进行选课了，但是学生可以将原来的选课信息删除再进行选课。

若学生毕业，需要将其账号删除。

（3）试对图书馆管理系统中书的状态进行分析；

十一、uml与软件工程区别

UML是软件工程的一个组成部分。

软件工程是从系统的、工程的角度来研究软件开发，从保证软件开发的各个过程来保证软件开发的质量。

而UML是统一建模语言，它作为一种工具，来对软件开发的过程进行有序的系统的管理，从而更加有效的实现软件工程的要求。

软件工程实际上就是对一个项目的从一开始的需求到最后的完成来一个总体的规划，而UML无非就是用一种比较形象的图画来展示项目系统的一个总体或局部的结构。

实验八运用UML进行系统分析与设计——图书管理系统的分析与设计

【实验题目】：

运用UML进行系统分析与设计—图书管理系统的分析与设计

【实验目的】：

熟悉和掌握使用软件工程开发工具进行软件系统的分析与设计

【实验内容】：

运用UML进行系统分析与设计—图书管理系统的分析与设计

一．概述

UML（UnifiedModelingLanguage）：

用于确定、展示、记录挼建系统的整个开发过程。

用例图：

对系统的功能进行分析，描述系统的功能性要求；

类图：

展示系统的结构；

活动图：

描述为了完成某个目标需要做的活动以及这些活动的执行顺序，多用于对系统的工作流程建模；

顺序图：

用来描述对象之间的交互序列及其发生顺序。

顺序图可以用来描述一个用例的实现，即说明对象如何通过交互来执行用例的行为。

通过一个或多个顺序图来描述实现用例的实现过程（对象交互过程）。

用例结构中，主事件流将有一个顺序图，而每个独立的用例分支流（扩充用例和包含用例）都分别有一个顺序图。

协作图：

交互的语境与参与交互的对象的相互关系和整体组织。

状态图：

用于展示一个对象在其生命周期中各个时期的状态及其变化规律图形。

用于捕获系统动态行为。

构件图：

描述系统物理实现方面的信息。

部署图：

描述系统的构件在节点上的部署和运行情况。

二．图书管理系统实例

2.1需求部分——用例

（1）需求获取——从系统的最终用户（读者、图书管理员）方获取系统的要求和规范：

1图书馆应用程序应当是图书馆的支持系统。

2图书馆把书籍和杂志借给借书者（读者）的条件是读者应当在该系统中注册过，同样书籍和杂志也应当在系统中注册过。

3图书馆处理购买新书或杂志的操作，畅销书或杂志应当多购几本，旧的书籍和杂志当它们过时或残破时就应适当把它们从书架上请下来。

4图书管理员是图书馆中的职员，他的职责就是与顾客（借书者）打交道并通过该系统完成工作。

5借书者可以预借一本当前不在图书馆中的书籍或杂志，当这本书被归还或被购入图书馆的时候，他就会接到通知；当借书者借到这本书或杂志的时候，预定就会被取消；也可以使用显示程序取消预借。

6图书馆可以很容易地创建，更新和删除系统中的书名，借书者，借阅情况以及预借情况等信息

7该系统可以运行于所有流行的操作系统，包括UNIX，Windows以及OS/2，它还应当有先进的友好的图形用户界面（GUI）。

8该系统应当很容易使用新的功能扩展。

9在本案例分析中，该系统的第一个版本不需要处理某个读者预借的书籍成为可借书籍时发送消息给读者的操作，也不需要检查某本书籍是否已经超时了。

（2）需求描述：

往往采用用例描述来进行，其中的关键用例可以结合活动图来描述其事件流。

例如借书用例的事件流可以表述如下：

（3）需求分析：

分析的目的是为了获得和描述系统中所有的要求，以及生成一个在该系统中定义关键域类的模型。

其目标是在开发者与制定要求的人之间建立相互理解和沟通，因此分析是一种典型的与用户或客户合作的行为。

在这个阶段开发者不应该考虑具体的代码或程序细节；这只是真正地理解要求和正在设计的系统的实际情况的第一步。

分析的第一步应当是判断该系统将被用于做什么以及谁将使用它。

这分别是所谓的用例（usecase）和参与者（actor）。

用例描述了图书馆系统具体应当提供哪些功能，即系统的功能要求。

一个用例分析过程包括阅读和分析规范，并且讨论该系统的潜在的用户（客户）。

图书馆中的参与者是图书管理员和借书者，图书管理员是该系统的用户而借书者则是顾客，查看并且预订书籍和杂志的人应该是借书者，但是有时候也可能是一个图书管理员或另外一个图书馆。

（4）需求验证：

与客户和领域专家进行沟通和交流，反复验证用例模型的准确性；

2.2设计部分

（1）问题域分析

分析过程中还要详细地列举讨论域（domain，系统中关键的类），为了进行讨论域分析，需要充分理解规范和用例并且着眼于系统将要处理的"概念"；或者与使用者及讨论域专家组织一次集体研讨会谈，尝试找出所有必须处理的关键概念以及它们之间的相互关系。

图书馆系统中的讨论域类如下：

:

BorrowerInformation（这样命名是为了区别于用例图表中的参与者Borrower），Title，BookTitle，Magazine，Item，Reservation和Loan。

下图是一张类图，标出它们的相互关系。

这些讨论域类是用户自定义的类，指定该类的对象是关键域的一部分并将被持久的保存在系统中。

可以对复杂的对象进行状态分析，建立状态图：

类的状态图，说明了可能的状态以及需要被处理的过渡期（以及触发该过渡期的操作）。

（2）行为建模（顺序图、协作图）

类的对象中包含的行为图（序列图、协作图）：

说明类的一个具体的方法的实现的图表或者是说明其他对象是如何使用类的对象的图表。

通过对行为的建模工作，开了解对象的交互，发现更多的没有发现的类对象，并进一步为类添加属性、方法（主要是发现类的方法）。

例：

以借书的基本事件流为例绘制其顺序图如下：

添加书目用例的基本事件流的交互

2.3实现部分

程序设计在构造或实现阶段就开始了，应用程序的要求规定本系统能够运行于各种不同的处理器和操作系统，因此.NET是实现本系统的最好的选择。

下图是实现“借书”功能的构件图：

2.4系统部署

说明：

本部分仅对“借书”环节进行了比较详细的说明，请试着对其他的部分进行分析与设计。

本部分草拟仓促，如有错误，请读者谅解。