第4章类图实战
4.1从分析到设计
首先，我们先来简单归纳一下在分析阶段生成的文件，如下：
1. 类图。类图描述系统内部的静态结构，以领域概念为参考对象。如果应用BCE 模式的话，原先的类图会是实体类图，而在序列图生成后，会额外生成边界类图和控制类图。
2. 用例图。用例图描述系统的外部行为，也就是描述参与者如何与系统交互，以便获取服务的使用过程。
3. 序列图。序列图描述系统的内部行为，针对每一个用例，至少会有一张描述主要流程的序列图。在应用BCE 模式之后，序列图内部的一群对象，将由边界对象、控制对象和实体对象所组成。换言之，序列图的一群对象必须来自于类图，而对象之间的交互过程，则来自于用例描述。
分析阶段与设计阶段最大的差别在于，分析阶段所关注的重点在领域概念、业务流程等，并未考虑并涉及实际工作平台。所以，到了设计阶段，不再需要花费太多时间在业务概念上，取而代之的是，必须把精力放在实际工作平台上，承接分析阶段的类图、用例图、序列图再加上实际工作平台或者是开发人员的观点，生成可以交付给程序员的设计文件。因此，在本书的开发流程规划中，我们会让设计师直接承接分析师的生成文件，进行下述的加工：
1. 类图。分析师所生成的类图通常跟实际工作平台有些差别，所以设计师要补上一些实际工作平台的概念，让设计出来的类图可以真正交付给程序员实际工作。
2. 用例图。之前我们没有教给分析师用例之间的包含关系和扩展关系如何处理，只是让用例图保持单纯化，以便将焦点聚焦在业务流程上。此处，我们会教设计师如何加入开发人员的观点，使用包含关系和扩展关系，罗列出可以共享的部分，并且让用例图更为细致化。
3. 序列图。在分析阶段的序列图并没有太重视消息上的参数，在设计阶段，每张序列图都要拿出来再检查一次，加上所需要的参数。由于，有些分析师已经太久没摸过程序代码了，所以生成的序列图偏离实际工作情况太大，需要设计师来补上这一块，否则程序员是很难直接参考分析文件编写程序代码。
好了，接下来，我们要再来多谈一些类图中的元素，这些元素可能对分析师意义不大，但是对设计师而言，会是非常实用的概念。
4.2设计师必学元素
4.2.1依赖关系
之前，我们学到了类之间的关联或组合关系，它们都是一种需要长期保存在数据库中的静态关系。相较之下，“依赖关系（dependency relationship）”是一种暂时的、动态的关系，它不需要被长期保存，可以在使用的瞬间建立，如果不用了就回收。
因此，当两个对象之间可以互传消息时，意味着两个对象之间存在需要长期保管的静态关系，或者是暂时性的动态关系。例如，在图4-1 中，边界对象与实体对象之间可以通过动态的依赖关系交互，用完就丢，不需要将这个动态关系保存在数据库中。而房型和景观图片两者之间由于存在组合关系，所以它们可以通过静态关系交互。
需要特别注意到，既然说是“依赖”则意味着连动性，支持端只要一变动，很可能客户端会受到连动。所以，在建构依赖关系时，被依赖的支持端愈稳定愈好，像是在BCE 模式的概念中，您会发现边界对象、控制对象比较不稳定，所以我们不让稳定的实体对象依赖它们，避免因此而导致整个结构的不稳定。
总之，如果两对象之间已经存在静态关系时，可以优先使用静态关系交互，而且记得要将静态关系保存在数据库中。如果两个对象之间没有静态关系，也可以建立暂时性的依赖关系，以便进行交互，而且用完即丢，不需要费心保存在数据库中。
4.2.2泛化关系
泛化关系（generalization relationship）是一种分类关系；针对同一种概念的事物，区分成一般性的（general）和特定性的（specific），然后再构建起两类之间的一般性关系。
例如，在订房系统中，我们可以将景观图片分为两大类：酒店图片和房型图片。相较于原先的景观图片，酒店图片和房型图片两者都属于较为特定的图片，因此我们可以通过泛化关系构建出三者的关系，如图4-3 所示。
在泛化关系中，有个很重要的特色是，子对象可以替代父对象；这是因为子类继承了父类的特征，具体来说，子类可以通过泛化关系继承父类的属性、操作与静态关系。还记得，前面我们说过静态关系是指关联，而组合关系则是关联的一种。
所以，请看图4-5 的例子，虽然酒店图片和房型图片并未定义任何属性、操作和关系，但其实它们已经拥有景观图片已经定义好的属性、操作和关系了，这就好比小孩继承了父母留下来的财产一样。
不过，在图4-5 的例子中，如果我们不想继承关系，可以改成图4-6 的设计，特别注意原来图4-5 中0..1 的多重性，到了图4-6 中则改成了1，这样才是正确的多重性。
再者，继承而来的属性、操作和关系，也可以在子类处“重新定义（redefine）”，不一定要全盘接受。例如，在景观图片中的“场所”属性并没有默认值，继承之后，我们在它的子类处加上了默认值，重新定义了场所，如图4-7 所示。
4.2.3保护等级
虽然，通过泛化关系，子类可以继承父类已经定义好的属性、操作和关系。不过，要是父类将这些成员定义成私有等级（private）的话，子类虽然还是可以继承，但是却无法在子类中直接访问私有成员，使用上颇为不便。特别是属性，一般为了封装性，都会建议设置成私有等级可见性。
4.2.5类层级
之前，我们所看到的属性和操作都属于“对象层级（object-scoped, instance-scoped）”，代表该类所生成的每一个对象都拥有一份对象层级的属性，而且外界也只能通过对象调用对象层级的操作。
相对的，有另一种称为“类层级（class-scoped, classifier-scoped）”的属性与操作，代表整个类共享一份属性，而且外界只要通过类就可以调用操作，不需要先生成对象。
例如，在订房系统中，会员类内部的“验证”操作，要是设置为类层级的操作，或许会比设置为对象层级的操作，更为恰当。因为，当我们请会员进行验证时，其实根本就还没有正确找出某一个会员对象，所以可能不是请某一个会员对象来进行验证，而是应该找会员类先进行验证，通过验证之后，再找出正确的会员对象才对。
所以，如图4-13 所示，类层级的属性与操作名称有下划线，之前我们看到没有下划线的属性或操作都属于对象层级的。还有，由所有会员对象共同维护一份会员总数量即可，所以这个属性也适合设置成类层级的属性。
另外，其他像生成对象、删除对象的操作，其实都适合设置成类层级，因为在对象生成之前，该对象根本不存在，怎么能请这个对象执行生成自己的动作呢？至于删除对象也应该同样交给所属类来执行，或许会比请对象自动释放，要合适得多。
4.2.7枚举类型
前面，我们都在谈类或对象，最后我们来看一个特殊的数据类型（data type）概念，即“枚举类型（enumeration）”。枚举类型也采用矩形图标，不过名称上面多了<
4.3从面向对象到关系型数据库
在UML 中，系统以对象的方式在运行，当然也包含以对象的方式存储在数据库中。可是，实际工作的中，并不总是如此完美，虽然面向对象数据库（Object-Oriented Database，OODB）已经发展多年，但关系型数据库却是目前的主流技术。
所以，从面向对象到关系型数据库，一直是一个鸿沟，却也是许多年来微软等大厂商一直努力投入的主题。所幸，近年来，关于“对象关系映射（Object-Relational Mapping, ORM）”技术有较大的进展，例如，Java 阵营发展出来的Hibernate，或是微软自家发展出来的“实体框架（Entity Framework）”，填补了面向对象与关系型数据库之间的鸿沟。因此，很幸运地，我们可以比过去的前辈们，更专心在面向对象技术中，无须太过担心数据库端的转换。
本书假设后端采用关系型数据库，而且我们也不愿意花时间绘制实体关系图（ERD）的情况下，设计师可以选择在类中加入关系型数据库的“主键（Primary Key，PK）”和“外键（foreign key, FK）”的概念，让实体类图可以一图两用，同时落实到程序代码和关系型数据库。
特别注意到，在面向对象的程序设计中，对象之间通过连接就可以连接到对方，因此类之间有静态关系，也就不需要额外加入键值，特别是外键的概念。所以，如4-17 所示，每一个类中的属性都是自己的属性，并没有抓别的类的属性过来当外键。
4.4酒店联合订房系统
4.4.1用例——会员登录
在会员登录用例中，主要用到“会员”实体类，如图4-20 所示。
至于主键的部分，之前举例时已经加工过了，这里就不再说明了；外键的部分，等出现与其他类之间的静态关系，再来修改。 4.4.2 用例——查询酒店数据
“查询酒店数据”用例很简单，连控制对象都没设置，仅做数据库查询的工作，它的BCE 类依赖关系如图4-22 所示。
在图4-23 中，有几个重点，如下：
1. 在景观图片的部分，我们并没有使用前面谈到的泛化架构，而是让酒店和房型都连到这个景观图片。所以，景观图片的外键会有两个来源，一个是来自酒店，另一个来自房型。因此，另外取了“场所序号（placeNumber）”做为景观图片的外键名称。
2. 再者，我们为景观图片的“场所（place）”属性，设计了一个PicturePlace 枚举类型，其枚举值有酒店和房型两个。
3. 至于酒店序号也一并通过“自动生成序号（NumberGenerator）”公有类自动生成。
4.4.3 用例——查询房型数据
见图4-24 关于“查询房型数据”的BCE 类图，其中的“景观图片（Picture ）”实体类前面已经加工过了，所以这里就仅列出实体类的图标，把它的属性和操作隐藏起来了。
接着，加工后的如图4-25 所示，几项重点内容介绍如下：
1. 房型类中的“计算房价”操作，一直都还没用到，所以我们就先把它删除了，日后有需要再补上。
2. 由于订房系统中可能会用到房间（Room ） 类， 所以这里的“房型”就翻译成“RoomType”了。
3. 还有，房型类已经有“床型（bed ）”属性了，所以似乎不再需要用到“种类”属性，所以我们也把这个属性删除了。
4. 再者，房型名称是指酒店经营者为房型取的名称，例如，尊贵总统房、紫色浪漫屋之类的房型昵称。
5. 自动生成序号（NumberGenerator ）公有类增加了一个“产生房型序号（generate-RoomTypeNumber ）”的操作，所以我们又将这个类更新了一次。
4.4.6 类图
还记得，我们在第2 章的末尾，汇总了一张类图，我把它贴到图4-30 中。在后续发展的用例中，都暂时没用到“入住”和“房间”这两个实体类，所以我想先删除它们，让类图简单些，如果我们分析新的用例使用到新的实体类，再来扩展实体类图好了。
软件工程作业用例图,状态 图类图 -标准化文件发布号：（9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII
软件工程设计方案 学院计算机学院 专业软件工程 班级 2012 级 4 班 学号 86 姓名黎伟杰 指导教师崔洪刚 （ 2015 年 1 月）
计算机学院软件工程专业12级4班班学号：86 姓名：黎伟杰协作者：________ 教师评定： 问题定义：为实现一个功能强大的学生宿舍管理信息系统，它主要实现对入住人员的管理及对宿舍的其它管理，如新生、老生的基本信息处理，毕业生退宿，水、电费的超额处理。该系统功能齐全，操作简便，实用性强，主要包括三个模块：资料管理模块、宿舍管理模块、收费管理模块最后还给出实现的设计思想和关键技术。 系统名称：学生宿舍管理系统 作者名称：广东工业大学计算机学院软件工程12（4）班86 黎伟杰 系统功能描述：随着计算机的应用与普及，现在越来越多的学校学生宿舍都是利用计算机来控制和管理的，学校的不断发展，人数的不断增长，生活水平的提高，要求也越来越高。为了改善学校的宿舍管理，为此开发了学生宿舍管理信息系统软件。本系统要学生用户对它进行查询，管理员有效地对它进行管理用户，即随时可以对它进行添加与删除，在没有旁人指导的情况下，用户也可以进入这个系统并且知道该如何使用它，比如，用户点击进入后就会出现一个系统登陆对话框，根据用户的用户名和密码，点击“登陆”按钮，就可进入系统。这个系统可以适用于各大院校，具有管理权限的用户可以对系统进行修改，没有此权限的用户只能对系统进行查询。 用例图：
数据流图：
UML中类图实例 接口：空心圆+直线（唐老鸭类实现了‘讲人话’）； 依赖：虚线+箭头（动物和空气的关系）； 关联：实线+箭头（企鹅需要知道气候才迁移）； 聚合：空心四边形+实线+箭头（雁群和大雁的关系）； 合成/组合：实心四边形+实线+箭头（鸟和翅膀的关系）；泛化/继承：空心三角形+实线（动物和鸟的继承关系）；实现：空心三角形+虚线（实现大雁飞翔的接口）； UML类图
解释UML类图： 1. 首先看“动物”矩形框，它代表一个类。该类图分为 三层，第一层显示类的名称，如果是抽象类就要用斜体显示。第二层是类的特性，通常就是字段和属性。第三层是类的操作，通常是方法和行为。
注意前面的符号，‘+’表示public, ‘—’ 表示private, ‘#’表示protected. 2. “飞翔”矩形框表示一个接口图，它与类图的区别主 要是顶端有《interface》显示，第一行是接口名称，第二行是接口方法。接口还有另一种表示方法，俗称棒棒糖表示法，就是唐老鸭类实现了“讲人话”的接口。 interface IFly interface Ilanguage { {
void Fly(); void Speak(); } } 3. 动物，鸟，鸭，唐老鸭他们之间都是继承的关系，继 承关系用空心三角形+实现来表示。 4.“大雁”实现了“飞翔”接口。实现接口用空心三角形+虚线来表 示。（注：下面的图中应为空心三角形）
class Bird:Animal clas s WideGoose:IFly { { //继承动物 类 //实现飞翔接口 } } 5. 企鹅与气候有很大的关系，企鹅需要“知道”气候的 变化，需要“了解”气候规律。当一个类“知道”另一个类时，可以用关联(association)关系。关联关系用实线箭头来表示。 class Penguin :Bird { private Climate climate;//在企鹅Penguin中，引用到气候Climate对象 }
通过四次实验，以图书管理系统建模为例，使学生掌握使用UML统一建模语言为软件系统建模的方法步骤。 二、实验内容与要求 图书管理系统需要满足三方面的需求，这三个方面分别是图书借阅者、图书馆工作人员（图书管理员）和图书馆管理人员（系统管理员）。图书借阅者的需求是查询图书馆所存的图书、个人借阅情况及个人信息的修改；图书管理员对图书借阅者的借阅及还书要求进行操作，同时形成借书或还书记录；系统管理员的功能最为复杂，包括对图书借阅者和图书进行管理和维护，及系统状态的查看、维护。 图书管理系统结构图 三、实验步骤 1、系统需求分析 建立用例图并进行用例描述 2、建立系统静态模型 类图的建立 3、建立系统动态模型 建立顺序图、协作图、活动图和状态图
（一）系统需求分析 1、读者用例： 用例描述 用例名称：借阅信息查询 参与执行者：借阅者 前置条件：合法用户登录到系统 基本事件流：系统显示书籍查询窗口 用户点击借阅信息 系统显示借阅信息 扩展事件流：系统提示没有借阅信息 用户点击该对话框 系统回到主界面 2、图书管理员用例图 用例描述 用例名称：归还图书 参与执行者：图书管理员 前置条件：合法图书管理员登录系统 基本事件流：系统显示图书借阅窗口 用户点击书籍归还处理 系统显示该借阅者的借阅信息
图书管理员将已归还的书籍从借阅信息中点击“已归还” 系统显示的借阅者信息里不再显示“借阅”这本书 扩展事件流：系统提示缴纳罚款 借阅者支付罚金 系统显示的借阅者信息里不再显示“借阅”这本书 3、系统管理员的用例图 用例描述 用例名称：图书添加 参与者：系统管理员 前置条件：合法系统管理员登录到系统 基本事件流：系统显示图书添加窗口 系统管理员点击图书添加窗口 系统按书的类别显示窗口 系统显示一个页面要求输入该书籍的编号，书籍名称等基本信息 系统管理员依次填写有关信息，最后点击确认 （二）建立系统静态模型 1、参与者相关的类 （1）读者类，属性包括：读者账户（userID）、姓名（name）、地址（address）、邮编（zip）、所借书籍的书目（borrow_back），操作包括：借书（borrow）、还书（return_back）。
图书馆管理系统 一．图书馆管理系统需求分析 1、系统目标设计 系统开发的总目标是实现内部图书借阅管理的系统化、规范化和自动化。 能够对图书进行注册登记，也就是将图书的基本信息（如：书的编号、书名、作者、价格等）预先存入数据库中，供以后检索。 能够对借阅人进行注册登记，包括记录借阅人的姓名、编号、班级、年龄、性别、地址、电话等信息。 提供方便的查询方法。如：以书名、作者、出版社、出版时间（确切的时间、时间段、某一时间之前、某一时间之后）等信息进行图书检索，并能反映出图书的借阅情况；以借阅人编号对借阅人信息进行检索；以出版社名称查询出版社联系方式信息。 提供对书籍进行的预先预订的功能。 提供旧书销毁功能，对于淘汰、损坏、丢失的书目可及时对数据库进行修改。 能够对使用该管理系统的用户进行管理，按照不同的工作职能提供不同的功能授权。 提供较为完善的差错控制与友好的用户界面，尽量避免误操作。 2、系统功能需求分析 (1)读者管理：读者信息的制定、输入、修改、查询，包括种类、性别、 借书数量、借书期限、备注等。 (2)书籍管理：书籍基本信息制定、输入、修改、查询，包括书籍编号、 类别、关键词、备注。 (3)借阅管理：包括借书，还书，预订书籍，续借，查询书籍，过期处 理和书籍丢失后的处理。 (4)系统管理：包括用户权限管理，数据管理和自动借还书机的管理
基于UML的图书馆管理系统建模设计 满足以上需求的系统主要包含有一下几个子系统 （1）基本业务功能子系统：该系统中主要包含了借书还书和预订等功能。 （2）基本数据录入功能子系统：该子系统主要包含有书籍信息和读者信息录入功能。 （3）信息查询子系统：包含了多功能的查询书籍信息和读者信息。 （4）数据库管理功能子系统：主要包含了借阅信息管理功能，书籍信息管理功能和预订信息管理功能。 （5）帮助功能子系统。 二、系统动态建模 1、用例图、
【用例图】 1.用例图的节点包括（ABD） A、用例 B、边界 C、关联 D、执行者 2.用例之间的关系主要有（BCD） A、聚合 B、继承 C、扩展 D、包含 3.在采用用例模型捕获需求时，需要执行如下（ABCD）操作A、描述非功能需求B、用例建模C、识别用例D、识别参与者 4.在识别用例时，以下（ABC）问题可以帮助识别用例 A、当系统状态发生故障时，是否需要通知参与者 B、系统是否存在外部事件，如果存在，是哪个能参与者通知系统这些个部事件 C、参与者希望系统为他提供什么样的功能 D、系统运行环境是什么 5.在用例图中，可以用（D）来表示整个软件系统或其中一些子系统的边界，也可以用它表示软件系统的不同发布版本的功能范围A、执行者B、关联关系C、用例D、边界框 6.（B）作为完成用例任务的责任承担者，协调、控制其他类共同完成用例规定的功能或行为 A、数据对象 B、控制类 C、实体类 D、边界类 7.基于用例图的需求捕获的第一步就是确定系统的参与者，在寻找系统参与者时，可以根据以下（ABCD）等问题来确定 A、系统同环境如何进行交互 B、由谁安装系统
C、系统为哪些对象提供信息、服务 D、系统的使用者是谁 8.如果用例B是用例A的某项子功能，并且建模者确切地知道在A所对应的动作序列中何时将调用B，则称（A） A、用例A扩展用例B B、用例A继承用例B C、用例A包括用例B D、用例A实现用例B 9.如果用例A与用例B相似，但A的动作序列是通过改写B的部分或者扩展B的动作而获得的，则称（B） A、用例A实现用例B B、用例A继承用例B C、用例A扩展用例B D、用例A包括用例B 10.如果用例A与用例B相似，但A的功能较B多，A的动作序列是通过在B的动作序列中的某些执行点上插入附加的动作序列而构成的，则称（C） A、用例A扩展用例B B、用例A包含用例B C、用例A继承用例B D、用例A实现用例B 11.在UML中，（A）表示使用软件系统的功能，与软件系统交换信息的外部实体
超市管理系统需求分析报告（使用面向对象的方法）
目录 1用例和用例图 (1) 1.1什么是用例和用例图 (1) 1.2用例图 (2) 1.3用例说明 (4) 2类图 (9) 2.1什么是类图 (9) 2.2类图 (10)
超市管理系统需求分析报告 （面向对象方法） 1用例和用例图 1.1 什么是用例和用例图 用例是由行为者启动的系统完成的一系列动作，这些动作除了完成系统内部的计算与工作外，还包括与一些行为者的通信。用例代表某些用户可见性的功能，实现一个具体的用户目标。 用例图（User Case）是由参与者，用例以及它们之间的关系构造成的用于描述系统功能的动态视图的图。用例图展示了用例之间以及同用例参与者之间是怎样相互联系的。用例图用于对系统、子系统或类的行为进行可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。用例图定义了系统的功能需求，它是从系统的外部看系统功能，并不描述系统内部对功能的具体实现。
1.2 用例图
1.3 用例说明 用例名称：超市管理系统之人事管理 相关活动者：职工，人事部人员，超市管理系统之售后服务 简要说明：人事部人员对职工进行人事调动，人事考核，培训，工资管理等一系列人事安排。一切的人事安排都打印出报表及时通知给职工。其中的人事考核将接受由超市管理系统之售后服务传过来的对职工的投诉的信息，作为人事考核的一个依据。 前置条件：人事部人员已经登录人事管理界面 主事件流： 1.人事部人员登录人事管理界面，用例开始 2.系统提示输入人事管理对象职工的职工号 3.人事部人员输入人事管理对象职工的职工号 4.系统提示选择人事管理的四项管理：人事调动，人事考核，培训，工资管理 5.人事部人员选择一项具体的人事管理：B1：选择人事调动B2：选择人事考核B3：
UML类图几种关系的总结 在UML类图中，常见的有以下几种关系: 泛化（Generalization）, 实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency) 1. 泛化（Generalization） 【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。例如：老虎是动物的一种，即有老虎的特性也有动物的共性。 【箭头指向】：带三角箭头的实线，箭头指向父类 2. 实现（Realization） 【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现. 【箭头指向】：带三角箭头的虚线，箭头指向接口
3. 关联（Association) 【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。 【代码体现】：成员变量 【箭头及指向】：带普通箭头的实心线，指向被拥有者 上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。
下图为自身关联： 4. 聚合（Aggregation） 【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。如车和轮胎是整体和部分的关系，轮胎离开车仍然可以存在。 聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。 【代码体现】：成员变量 【箭头及指向】：带空心菱形的实心线，菱形指向整体
第一章系统建模与分析设计的演变 课后习题： 1、A 2、C 3、D 4、B 5、软件按照其工作方式可划分为实时处理软件、分时处理软件、交互式软件和批处理软件。 6、软件生存周期由软件的定义、软件的开发和软件的使用维护和更新换代三部分组成。 7、软件开发模型有瀑布模型、增量模型、螺旋模型、智能模型和快速原型模型等五种主要模型 8、面向对象技术采用以类为中心的封装、继承、多态等不仅支持软件复用，而且使软件维护工作可靠有效，可实现软件系统的柔性制造。 9、UML的优点是：唯一性、连续性、维护性、复用性和完善性。 第二章统一建模语言UML 1、A 2、B 3、C 4、D 5、B 6、UML分析和设计模型由三类模型图表示，三类模型图是：用例模型图、静态模型图和动态模型图。 7、UML的软件统一开发过程，即生命周期按时间顺序可以划分为，开始，详细设计，系统构造和移交四个阶段及阶段中一系列的循环重复。 8、UML开发过程是一种二维结构软件开发过程，软件项目开发过程流程包括的核心工作内容是，分析，设计，实现，测试和配置 9、UML中的五个不同的视图可以完整地描述出所建造的系统，这五种视图是用例视图、逻辑视图、构件视图、进程视图和配置视图。 10、UML中有10中基本图可以完整地描述出所有建造的系统，这10中视图是用例图、类图、对象图、包图、构件图、配置图、序列图、活动图、状态图和合作图。 第三章需求分析与用例建模 习题： 1、B 2、A 3、C 4、D 5、B 6、A 7、A 8、UML软件开发过程需求分析阶段产生的模型由三类模型图表示。他们是：用例模型图、静态模型图和动态模型图。 9、CRC卡中的描述由类名、类特征、类类型、责任和协作者共五部分组成 10、软件项目的目的的可行性研究分析中，技术可行性研究包括风险分析、资源分析、技术分析三部分组成 11、在UML软件开发过程的需求分析阶段，建立用例模型的步骤分为，确定系统的范围和边界，确定系统的执行者和用例，对用例进行描述，定义用例之间的关系和审核用例模型。12、用例图中以实践方框表示系统的范围和边界，在熊边界内描述的是用例，在边界之外描述的是执行者 13、用例模型中的执行者可以是“人”执行者也可以是“外部”系统执行者 14、用例模型中的用例之间的关联有使用关联、扩展关联。包含关联和继承关联 第四章系统分析与对象类建模 习题
第6章用例图 3. 简答题 （1）试述识别用例的方法。 答：识别用例的最好方法就是从分析系统参与者开始，在这个过程中往往会发现新的参与者。 当找到参与者之后，我们就可以根据参与者来确定系统的用例，主要是看各参与者如何使用系统，需要系统提供什么样的服务。 对于这个被选出的用例模型，不仅要做到易于理解，还要做到不同的涉众对于它的理解是一致的 （4）请简述为何在系统设计时要使用用例图及其对用户有什么帮助？ 答：用例图是从软件需求分析到最终实现的第一步，它显示了系统的用户和用户希望提供的功能，有利于用户和软件开发人员之间的沟通。 借助于用例图，系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。 第7章类图与对象图 3. 简答题 （3）简述使用类图和对象图的原因。 答：在面向对象分析方法中，类和对象的图形表示法是关键的建模技术之一。它们能够有效的对业务领域和软件系统建立可视化的对象模型，使用强大的表达能力来表示出面向对象模型的主要概念。 UML中的类图和对象图显示了系统的静态结构，其中的类、对象是图形元素的基础。（4）请简要说明类图和对象图的关系和异同。 答：在类中包含三个部分，分别是类名、类的属性和类的操作。类的名称栏只包含类名。类的属性栏定义了所有属性的特征。类中列出了操作类中使用了关联连接，关联中使用名称、角色以及约束等特征定义。类是一类的对象的抽象，类不存在多重性。 对象包含两个部分：对象的名称和对象的属性。对象的名称栏包含“对象名：类名”。对象的属性栏定义了属性的当前值。对象图中不包含操作内容，因为对属于同一个类的对象，其操作是相同的。对象使用链进行连接，链中包含名称、角色。对象可以具有多重性。 类与类之间的主要关系有几种？它们的含义是什么？ 答： a.泛化关系：泛化是一种继承关系，表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。 b.实现关系：用于规定规格说明与其实现之间的关系，换句话说，就是指定两个实体之间的一个合同，一个实体定义一个合同，而另一个实体保证履行该合同。 c..关联关系：对象之间的关系准则。 聚合关系：它是一种特殊的关联关系，它表示整体与部分的关系，且部分可以离开整体而单独存在。
UML实践----用例图、顺序图、状态图、类图、包图、协作图 2009-01-20 作者：Randy Miller 来源：网络 面向对象的问题的处理的关键是建模问题。建模可以把在复杂世界的许多重要的细节给抽象出。许多建模工具封装了UML（也就是Unified Modeling Language?），这篇课程的目的是展示出UML的精彩之处。 UML中有九种建模的图标，即： ?用例图 ?类图 ?对象图 ?顺序图 ?协作图 ?状态图 ?活动图 ?组件图 ?配置图 本课程中的某些部分包含了这些图的细节信息的页面链接。而且每个部分都有一个小问题，测试一下你对这个部分的理解。 为什么UML很重要？ 为了回答这个问题，我们看看建筑行业。设计师设计出房子。施工人员使用这个设计来建造房子。建筑越复杂，设计师和施工人员之间的交流就越重要。蓝图就成为了这个行业中的设计师和施工人员的必修课。 写软件就好像建造建筑物一样。系统越复杂，参与编写与配置软件的人员之间的交流也就越重要。在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”。现在它已经成为了软件行业的一部分了。UML提供了分析师，设计师和程序员之间在软件设计时的通用语言。 UML被应用到面向对象的问题的解决上。想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的。一个模型model就是根本问题的抽象。域domain就是问题所处的真实世界。 模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的。记住把一个对象想象成“活着的”。对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）。对象的属性的值决定了它的状态state。 类Classes是对象的“蓝图”。一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）。对象是类的实例instances。 用例图 用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象。强调这个系统是什么而不是这个系统怎么工作。 用例图与情节紧紧相关的。情节scenario是指当某个人与系统进行互动时发生的情况。下面是一个医院门诊部的情节。 “一个病人打电话给门诊部预约一年一次的身体检查。接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录。”
填空题 第一章 (1)统一建模语言UML是绘制软件蓝图的标准工具语言， (2)UML (3) (4)(抽象) 第二章 (1) 在UML 是UML常用的通用机制。 是UML常用的扩展机制。 的系统功能的模型图。 (5) 并 且它是独立的对象为中心进行描述。 第三章 (1)Rational Rose默认支持的目标语言主要包括C++，C#） ,它是为了便于理解系统如何在一组处 理解节点上的物理分布，而在分析和设计中使用的架构视图。
(3)使用Rational Rose 生成代码的步骤包括选择待转换的目标模型、检查Java语言的语法错误、设置代码生成属性、生成代码。 (4)在用例视图中包括了系统中的所有参与者、用例和用例图，必要时还可以在其中添加顺序图、协作图、活动图和类图等。 (5) 构件视图用来描述系统中的各个实现模块以及它们之间的依赖关系包含模型代码库、执行文件、运行库和其他构件等信息。 第四章 (1)对象图的目的在于描述系统中参与交互的各个对象在同一时刻是如何运行的。 (2)链是两个或多个对象之间的独立连接，是关联的实例。 (3)在UML的图形表示中，类是由名字、属性和方法三个部分组成的。 (4)依赖关系使用一个从客户指南提供者的虚箭头来进行表示。 (5)在接口中包含一系列操作但是不包含属性，并且它没有对外界可见的关联。 第五章 1）包是用于把元素组织成组的通用机制。 （2）包的可见性关键字包括private、public和protect。 （3）包之间的关系总的来讲可以概括为依赖关系和嵌套关系。 （4）将系统分层很常用的一种方式是将系统分为用户界面层、业务逻辑层和数据访问层的三层结构。 （5）包是包图中最重要的概念，它包含了一组模型元素。
UML各种图例 面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML（也就是Unified Modeling Language?），这篇课程的目的是展示出UML的精彩之处. UML中有九种建模的图标，即： ?用例图 ?类图 ?对象图 ?顺序图 ?协作图 ?状态图 ?活动图 ?组件图 ?配置图 本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题，测试一下你对这个部分的理解. 为什么UML很重要? 为了回答这个问题，我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂，设计师和施工人员之间的交流就越重要.蓝图就成为
了这个行业中的设计师和施工人员的必修课. 写软件就好像建造建筑物一样.系统越复杂，参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师，设计师和程序员之间在软件设计时的通用语言. UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界. 模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）.对象的属性的值决定了它的状态state. 类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）.对象是类的实例instances. 用例图 用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作. 用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节. “一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录.” 用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association（或简称通讯communication）
一、类图
类图分三层： 第一层显示类的名称。如果是抽象类，则就用斜体显示。 第二层是类的特性，通常就是字段和属性。 第三层是类的操作，通常是方法或行为。 注意前面的符号，“+”表示 public ，“-”表示private ，“#”表示protected 。 二、接口图 接口的两种表示方法 —— “飞翔”，它表示一个接口图，与类图的区别主要是顶端有<
三、关系 1、继承关系(Generalization)：也称泛化关系。 用 空心三角形 ＋ 实线 来表示 说明：和“接口实现”为一对，两者都用空心三角形。但继承关系比实现接口关系耦合性强，所以继承用实线，实现接口用虚线 2、合成关系(Composition)： 用 实心的菱形 ＋ 实线箭头 来表示。 也有翻译成“组合、复合”的。是一种强的“拥有”关系。 它体现了严格的部分和整体的关系，部分和整体的生命周期一样。 比如鸟和翅膀就是组合关系，因为他们是部分和整体的关系，并且翅膀和鸟的生命 周期是相同的。 另外，合成关系的连线两端还有一个数字“1”和数字“2”，这被称为基数。表明这一端的类可以有几个实例。 例如鸟有两个翅膀，两条腿，一个头等。如果一个类可以有无数个实例就用“n”来 表示，例如鸟可以有“n”个羽毛。 关联关系、聚合关系也可以有基数。 继承泛化 空三实线合成耦强 实菱实乮线乯箭 继承接口 合成聚合 关联依赖
UML系统建模基础教程课后答案 第一章面向对象设计与UML (1)UML （2）封装继承多态 （3）继承 （4）瀑布模型喷泉模型基于组件的开发模型XP开发模型 2.选择题 （1） C （2） A B C D （3） A B C D （4）ABC 3?简答题1?试述对象和类的关系。 （1）类是具有相同或相似结构、操作和约束规则的对象组成的集合，而对象是某一类的具体化实例，每一个类都是具有某些共同特征的对象的抽象。类与对象的关系就如模具和铸件的关系，类的实例化结果就是对象，而对一类对象的抽象就是类?类描述了一组有相同特性和相同行为的对象。 第二章UML通用知识点综述
1?填空题 （1）依赖泛化关联实现 （2）视图图模型元素 （3）实现视图部署视图 （4）构造型标记值约束 （5）规格说明修饰通用划分 2.选择题 （1）D （2）C （3）A （4） A B （5）D 3?简答题 （1 ）在UML中面向对象的事物有哪几种？ 在UML中，定义了四种基本的面向对象的事物，分别是结构事物、行为事物、分组事物和注释事物等。 （2 ）请说出构件的种类。 构件种类有：源代码构件、二进制构件和可执行构件。 （3）请说出试图有哪些种类。 在UML中主要包括的视图为静态视图、用例视图、交互视图、实现视图、状态机视图、活动视图、部署视图和模型管理视图。 （4 ）请说出视图和图的关系。
视图和图是包含和被包含的关系。在每一种视图中都包含一种或多种图 （5）请简述UML的通用机制。 UML提供了一些通用的公共机制，使用这些通用的公共机制（通用机制）能够使UML在各种图中添加适当的描述信息，从而完善UML的语义表达。通常，使用模型元素的基本功能不能够完善的表达所要描述的实际信息，这些通用机制可以有效地帮助表达，帮助我们进行有效的UML建模。UML提供的这些通用机制，贯穿于整个建模过程的方方面面。前面我们提到，UML的通用机制包括规格说明、修饰和通用划分三个方面。 第三章Rational统一过程 1?填空题 （1）角色活动产物工作流 （2）逻辑视图过程视图物理视图开发视图用例视图 （3）设计开发验证 （4）二维 （5）周期迭代过程里程碑 2?选择题 （1） A B C D （2） A C D （3） A C D （4）ABC （5） A B C D
根据UML图，写出Java程序的代码。 class MyClass { Student myStudent; String ClassName; private int StudNum; public void addStudent(Student stud) { myStudent= stud; } } class Student { long StudentID; private String StudentName; private String PassWord; public String getName() { return StudentName; } void changePassWord(String newPWD) {this. PassWord = newPWD; } }
interface ILeanable { public void study(); } interface ITeacher {public void teach(); } class Person { public String name; } class Student extends Person Implements ILeanable { private int age; private String address; public void study() {….} } class T eacher extends Person Implements ITeacher { private String major; private int age; public void teach() {…} }
图书馆管理系统用例图活动图类图时序图 集团标准化办公室：[VV986T-J682P28-JP266L8-68PNN]
图书馆管理系统 一．图书馆管理系统需求分析 1、系统目标设计 系统开发的总目标是实现内部图书借阅管理的系统化、规范化和自动化。 能够对图书进行注册登记，也就是将图书的基本信息（如：书的编号、书名、作者、价格等）预先存入数据库中，供以后检索。 能够对借阅人进行注册登记，包括记录借阅人的姓名、编号、班级、年龄、性别、地址、电话等信息。 提供方便的查询方法。如：以书名、作者、出版社、出版时间（确切的时间、时间段、某一时间之前、某一时间之后）等信息进行图书检索，并能反映出图书的借阅情况；以借阅人编号对借阅人信息进行检索；以出版社名称查询出版社联系方式信息。 提供对书籍进行的预先预订的功能。 提供旧书销毁功能，对于淘汰、损坏、丢失的书目可及时对数据库进行修改。 能够对使用该管理系统的用户进行管理，按照不同的工作职能提供不同的功能授权。 提供较为完善的差错控制与友好的用户界面，尽量避免误操作。 2、系统功能需求分析 (1) 读者管理：读者信息的制定、输入、修改、查询，包括种类、性 别、借书数量、借书期限、备注等。 (2) 书籍管理：书籍基本信息制定、输入、修改、查询，包括书籍编 号、类别、关键词、备注。 (3) 借阅管理：包括借书，还书，预订书籍，续借，查询书籍，过期处 理和书籍丢失后的处理。
(4)系统管理：包括用户权限管理，数据管理和自动借还书机的管理 满足以上需求的系统主要包含有一下几个子系统 （1）基本业务功能子系统：该系统中主要包含了借书还书和预订等功能。 （2）基本数据录入功能子系统：该子系统主要包含有书籍信息和读者信息录入功能。 （3）信息查询子系统：包含了多功能的查询书籍信息和读者信息。 （4）数据库管理功能子系统：主要包含了借阅信息管理功能，书籍信息管理功能和预订信息管理功能。 （5）帮助功能子系统。 二、系统动态建模 1、用例图、
超市管理系统U M L类 图和用例图 集团标准化工作小组 #Q8QGGQT-GX8G08Q8-GNQGJ8-MHHGN#
超市管理系统需求分析报告（使用面向对象的方法）
目录
超市管理系统需求分析报告 （面向对象方法） 1用例和用例图 1.1 什么是用例和用例图 用例是由行为者启动的系统完成的一系列动作，这些动作除了完成系统内部的计算与工作外，还包括与一些行为者的通信。用例代表某些用户可见性的功能，实现一个具体的用户目标。 用例图（User Case）是由参与者，用例以及它们之间的关系构造成的用于描述系统功能的动态视图的图。用例图展示了用例之间以及同用例参与者之间是怎样相互联系的。用例图用于对系统、子系统或类的行为进行可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元 素。用例图定义了系统的功能需求，它是从系统的外部看系统功能，并不描述系统内部对功能的具体实现。 1.2 用例图 1.3 用例说明 用例名称：超市管理系统之人事管理 相关活动者：职工，人事部人员，超市管理系统之售后服务 简要说明：人事部人员对职工进行人事调动，人事考核，培训，工资管理等一系列人事安排。一切的人事安排都打印出报表及时通知给职工。其中的人事考
核将接受由超市管理系统之售后服务传过来的对职工的投诉的信息，作为人事考核的一个依据。 前置条件：人事部人员已经登录人事管理界面 主事件流： 1.人事部人员登录人事管理界面，用例开始 2.系统提示输入人事管理对象职工的职工号 3.人事部人员输入人事管理对象职工的职工号 4.系统提示选择人事管理的四项管理：人事调动，人事考核，培 训，工资管理 5.人事部人员选择一项具体的人事管理：B1：选择人事调动 B2：选择人事考核 B3：选择培训 B4：选择工资管理 6.系统按选择做相关处理 7.用例结束 可选事件流： B1：选择人事调动 1.系统提示选择人事调动中三项管理：就职，职位变更，离 职 2.人事部人员选择一项具体的人事调动管理：B5：选择就职 B6：选择职位变更 B7：选择离职 3.系统按选择做相关处理 4.返回主事件流第7步 B2：选择人事考核
1、关联 双向关联： C1-C2：指双方都知道对方的存在，都可以调用对方的公共属性和方法。 在 GOF的设计模式书上是这样描述的：虽然在分析阶段这种关系是适用的，但我们觉得它对于描述设计模式内的类关系来说显得太抽象了，因为在设计阶段关联关系必须被映射为对象引用或指针。对象引用本身就是有向的，更适合表达我们所讨论的那种关系。所以这种关系在设计的时候比较少用到，关联一般都是有向的。 使用ROSE 生成的代码是这样的： class C1 ...{ public: C2* theC2; }; class C2 ...{ public: C1* theC1; }; 双向关联在代码的表现为双方都拥有对方的一个指针，当然也可以是引用或者是值。
单向关联: C3->C4：表示相识关系，指C3知道C4，C3可以调用C4的公共属性和方法。没有生命期的依赖。一般是表示为一种引用。 生成代码如下： class C3 ...{ public: C4* theC4; }; class C4 ...{ }; 单向关联的代码就表现为C3有C4的指针，而C4对C3一无所知。 自身关联（反身关联）： 自己引用自己，带着一个自己的引用。 代码如下：
class C14 ...{ public: C14* theC14; }; 就是在自己的内部有着一个自身的引用。 2、聚合/组合 当类之间有整体-部分关系的时候，我们就可以使用组合或者聚合。 聚合：表示C9聚合C10，但是C10可以离开C9而独立存在（独立存在的意思是在某个应用的问题域中这个类的存在有意义。这句话怎么解，请看下面组合里的解释）。 代码如下： class C9 ...{ public: C10 theC10; }; class C10 ...{
1.UML如何表示类?类图标中可以指明哪些信息? 类是描述一类对象的特征和行为，类图包含一组、接口及他们之间的关联、依赖和泛化的关系。它不仅显示了信息的结构，同时还描述了系统对象的的行为。 2.什么是类的多重性(关联的基数)?多重性怎么表示? 多重性是对象之间关联的一个重要方面，它说明了在关联中的一个类的对象可以对应另一个类的多个对象。 主要包含一组上下限数，用来指出可被允许生成的实例（instance）数量，即最多可以生成多少数目（上限），最少不得低于多少数目（下限）。关联的两端以"下限..上限"的格式标示出多重性，如图2-12中的1..*。星号（*）代表无指定上限，下限最低为0。如果上下限数相同，标示出一个数目就可以了 3.两者对象之间能够以多种方式关联吗？ 关联两边的"employee"和“employer”标示了两者之间的关系，而数字表示两者的关系的限制，是关联两者之间的多重性。通常有“*”（表示所有，不限），“1”（表示有且仅有一个），“0...”（表示0个或者多个），“0，1”（表示0个或者一个），“n...m”(表示n到m个都可以),“m...*”（表示至少m个）。在关联中有一种叫“限定关联”，还有一种谓之自身关联。另外，对象之间的关联就没那么复杂，只是将类的关联实例化而已 4.什么是约束？为什么要对类图附加注释？ 约束用来约束MUL成员的语义。约束用举例在大括号内的条件来表示（｛contrraint｝），可以直接放在图中，类图除了在设计新系统方面的用途外，它们还能用来记录一个存在系统（称它为“遗产”）的对象现在如何交互 5.聚集和组成之间有什么区别？ 聚合关系完全是概念上的，只是区分了整体与组成部分，没有改变整体与其组成部分之间的关联导航的含义，也没有将整体与部分的生命周期联系起来。而组合是聚合的变种，整体与部分之间有很强的所有关系，也就是说，在组合关系中，一个对象一次只是一个组合的一部分，而在简单的聚合关系中，一个部分可以被好几个整体共享。 另外，在组合关系中，整体负责部分的创建和破坏，部分的生命周期是依附于整体的，要么和整体一起创建和破坏，要么在整体存在后创建或在整体破坏前破坏，总之它不能单独存在。 6.什么叫实现?实现和继承有何相似之处？两者又有何不同之处？ 答：实现是类和它的接口之间的关系，可以说成是类实现了它的接口。相似之处：在于类可以使用它的接口中的操作，也可以操作从父类中继承操作。不同之处：类不能使用它的接口中的属性但可以继承父类中的属性。实现是对接口而言的，继承是对类而言的。 7.写出3种可见性的名称，并描述每一种可见性的含义。 答：public，protected，private及package。
一、选择题 1.软件设计中的（）设计指定各个组件之间的通信方式以及各组件之间如 何相互作用。 A．数据 B．接口 C．结构 D．组件 2.UML 是一种（）。 A．面向对象的程序设计语言 B．面向过程的程序设计语言 C．软件系统开发方法 D．软件系统建模语言 3.面向对象中的（）机制是对现实世界中遗传现象的模拟，通过该机制，基 类的属性和方法被遗传给派生类。 A．封装 B．多态C．继承 D．变异 4.下面关于类、对象和实例的叙述中，错误的是（）。 A 类是创建对象的模板 B 对象是类的实例 C 类是对象的实例 D 类是一组具有共同特征的对象集合 5.下列不在UP的初始阶段中完成的 A编制简要的愿景文档 B粗略评估成本 C定义大多数的需求 D业务案例 6.下面那一种模式是不属于GRASP模式的 A 多态（Ploymorphism） B 行为对象（pure fabrication） C 中间者（Indirection） D GoF 7.类是一组具有相同属性的和相同服务的对象的抽象描述，类中的每个对象都 是这个类的一个。 A例证 B用例C实例 D例外 8.类之间共享属性与服务的机制称为（22）。 A多态性B动态绑定 C静态绑定D继承 9.一个对象通过发送来请求另一个对象为其服务。 A调用语句B消息C命令D口令 10.下面的陈述中，对迭代和增量式开发描述错误的是（）。 A. 迭代是时间定量的 B. 系统是增量式增长的 C. 迭代是以循环反馈和调整为核心驱动力的 D. 当迭代无法依照时间表来集成、测试和稳定局部系统时，可以推迟完成 日期。 11.有关UP阶段的说法，不正确的是（） A. UP的一个开发周期（以系统发布作为产品结束标志）由多个迭代组成； B. 初始阶段不是需求阶段，而是研究可行性的阶段。 C. 细化阶段就是需求或设计阶段； D. 细化阶段就是迭代地实现核心架构并解决高风险问题的阶段； 12.下面关于领域模型的描述，不正确的是（） A. 领域模型就是软件对象图； B. 应用UML表示法，领域模型被描述为一组没有定义操作的类图； C. 创建领域模型的原因之一是帮助理解关键业务概念和词汇； D. 领域模型和领域层使用相似的命名可以减少软件表示与我们头脑中的领
Fox-ERP人事管理系统(二) -----毕业设计(论文) 指导老师 专业计算机应用与维护 组长 班级 组员 成都电子机械高等专科学校 2007年5月10日 目录
第一章系统功能 (1) 1.1需求分析 (3) 1.2F O X-E R P人事管理系统功能 (4) 第二章系统分析图....................................................................................... - 5 -2.1U M L图.. (5) 2.1.1用例图 (6) 2.1.2类图 (8) 2.1.3活动图 (9) 2.2系统架构 (9) 第三章主要关键技术 (10) 3.1关键技术之一 (10) 3.2关键技术之二 (11) 3.3关键技术之三 (11) 第四章数据库结构 (12) 4.1数据库设计 (12) 4.2人事管理系统的数据模型图 (16) 第五章使用FOX-ERP人事管理系统说明书 (16) 5.1F O X-E R P人事管理系统平台 (16) 5.1.1 硬件需求 (16) 5.1.2 安装: (17) 5.1.3第二期工程的后续工作 (17) 5.2F O X-E R P人事管理登录和进入系统 (17) 5.2.1 登录 (17) 5.2.2 进入FOX-ERP人事管理系统主界面 (17) 5.2.3 使用说明 (18) 第六章 FOX-ERP人事管理主要源程序....................................................................... - 32 -一、密码的修改和找回 .. (35) 1：修改密码代码 (32) 2：找回密码代码 (32) 二、员工就职 (33) 1：代号档资料维护界面代码 (33) 2：员工基本资料 (35) 3：津贴/扣款维护 (38) 4: 健保眷属资料维护代码 (39) 5：经历资料维护代码 (40) 6：证照资料维护代码....................................................................................... - 38 - 7: 技能资料维护代码....................................................................................... - 44 - 三、人事异动. (43) 1：就职单维护代码 (43) 2：调职单维护代码 ........................................................................................ - 51 - 3：离职单维护代码 ........................................................................................ - 53 -4：复职单维护代码 .. (47) 四、教育训练 (60) 2：教育训练员工文件维护 (50) 3：教育训练课程名单 (51) 4：教育训练上课员工名单 (51) 五、考绩与奖惩作业 (51) 1：考绩资料添加 (51) 2：考绩资料维护 (52) 3：奖惩资料添加 (53) 4：奖惩资料维护 (54) 六、退休作业 (55) 1：退休员工就职文件维护 (55) 2：未来退休员工预估表 (56) 七、用户注册 (57) 1：设置用户 (57) 2：用户注册 (57) 总结 (58) 主要参考文献 (59) 谢辞 (59)