Enterprise Architect UML指南
https://www.doczj.com/doc/e13117680.html,/resources/tutorial/uml-tutorial.html
1.应用UML进行数据库建模
1.1介绍
当需要为软件系统系统提供一种可靠，灵活而又高效的对象持久化方法时，当今的设计师和架构师们面临着众多的选择。从技术的层面上，这个选择往往介于完全面向对象，对象关系混合，完全关系化和建立在公开或专有文件格式上的常规解决方案之间（如：XML，OLE的结构化存储）。从提供者的层面上，Oracle，IBM，Microsoft，POET 和其它的公司提供了相似，但是彼此间往往不相容的解决方案。
本文仅论述这些选择中的一种，即在完全关系数据库上层面向对象的类模型进行分层。这并不表明它是唯一、最好而又简单的解决方案，但是从实用的角度看，它是最常用的一种类型，却也是最容易被用错的一种。
我们先快速浏览两个设计领域的模型，并试图把它们连接起来：第一，介绍用UML表达面向对象的类模型；第二，关系数据库模型。
对每一个领域我们只涉及影响到我们任务的主要功能。然后我们将关注从类模型到数据库模型映射的技术和问题，包括对象持久性，对象行为，对象和对象标识之间的关系。我们将总结对UML数据profile的回顾（Rational Software 推荐）。一些面向对象设计，UML 和关系数据库建模的相似性也会被提及。
类模型是UML用来表达软件系统逻辑结构的主要工件。它用来记录数据需求和模型领域内对象的行为。本文不讨论创建和详细描述该模型的技术，我们将假设已经存在一个设计好的类模型，它需要映射到关系数据库上。
类模型
类在UML中是一个基本的逻辑实体。它定义了一个结构单元的数据和行为。一个类是一个模板或运行时创建实例和对象的模型。当开发一个逻辑模型，如UML中的结构层次，我们将明确地把它们当作类来处理。当面对动态图时，如顺序图和协作图，我们也要处理类的实例和对象，以及它们运行时的内部动作。数据隐藏和封装原则是基于作用域效果。类有它的内部数据元素。访问这些数据元素需要通过类对外的行为或接口。遵循这个原则会生成
更易于维护的代码。
行为
行为使用了类定义的操作，在类模型中被记录。操作是可以外部可见的（public），对子类可见的（protected）和隐藏的（private）。通过结合隐藏数据和公共访问接口，隐藏或保护数据的操作，类的设计人员可以建立极易维护的结构单元，这些结构单元是支持而不是阻碍变化的。
关系和特性
关联是两个类之间的一种关系。关系一侧的类知道和在某种程度上使用或操控另一侧的类。这种关联可以是功能上的（为我做某事）也可以是结构上的（是什么）。在本文中更多的是侧重结构上的关系。如：一个“Address”类可以关联一个“Person”类，将这种关系映射到数据空间需要多加注意。
聚合是关联的一种形式，表示一个类多个对象的集合在另一个类中。复合是一种更强的聚合形式，说明一个对象实际上由其它对象构成。对于关联关系来说，它意味着一个复杂的类属性，将该属性映射到关系模型时需要更详细的考虑。当一个类表示为生成许多对象实例的模板或模型时，对象需要在运行时有识别自己的方式，这样被关联对象可以对正确的对象实例施加作用。在编程语言中，如C＋＋，对象指针可能会传递，并使所指对象可以访问一个独一无二的对象实例。通常尽管一个对象会被销毁，但是在需要时，又象上一次有效实例期间那样被重建。所以，这些对象需要一个存储机制来保留它们的内部状态和关联，并在需要时恢复所需状态。
继承给类模型提供一种方式，该方式提取通用行为到泛化的类中，使这个泛化类稍后可以做为在一般主题上诸多变异的原形。继承是一种管理重用和复杂性程度的方式。如我们将看到的，关系模型并没有与继承关系的直接对应项，这给数据模型建立者建立一个从对象模型到关系框架造成了困难。从一个运行时的对象到另外一个对象的导航是建立在完全引用的基础之上。一个对象有多种形式的连接（指针或唯一的对象标识），用这些连接可以定位和重建所需的对象。
关系模型
关系数据模型已经使用多年，提供的性能和灵活性一直行之有效。它本质上是基于集合的（set－based），并且用‘表’做为它的基本单元，表由一个或多个‘列’组成，每一个列包含一个数据元素。
表和列：一个关系表是一个或多个列的集合，每个列在表结构中有一个唯一名称，并且被定义成一个特定基本数据类型，如：数字、文本、二元数据。表定义是一个模板，表的“行”从这个模板中被创建，行可能做为一个表实例的实例。关系模型仅仅提供一个公共数据访问的模型。所有数据向外对任何一个过程开放，以便于被更新，查询和操控。信息隐蔽（information hiding）是未知的。
行为
与表相关联的行为通常是基于所应用实体的业务或逻辑规则。约束以多个形式应用到“列”，如：独特性需求、对应其它表和列的关系完整性约束，允许的值和数据类型。
触发器提供了关联到一个实体的许多附加行为。通常在数据被插入、删除和更新前后，强制执行数据的完整性检查。数据库存储过程提供了一种通过专有语言扩展来延伸数据库功能的方式，这些扩展通常用来构造功能性单元（脚本）。这些功能不会直接映射到这些实体，
也不会与它们有逻辑关系。通过关系数据集的导航是基于“行”遍历和表连接实现。SQL 是用来从表集选择“行”和放置实例的一种主要的语言。
关系和识别
表的主键为识别行提供一个特定值。这里有两种我们关注的主键：首先是意义键（meaning key），它由数据列构成，这些数据列在业务领域有意义。其次是一个抽象的唯一标识符，如计数器值，它没有商业意义，但是可以唯一地标识一个行。我们将先讨论抽象唯一标识符，然后再阐述意义键。一个表可以包含映射到另一个表主键的“列”。表间的关系定义了一个外键，说明了在这两个表之间的结构关系或关联。
小节
从以上的概述，我们可以看出对象模型是建立在离散实体基础上，这些实体既有状态（属性和数据），也有行为，一般仅通过类的公共接口来访问封装数据。关系模型同等地显露所有数据，有限支持利用触发器从行为到数据元素的关联。依靠使用唯一对象标识符，可以从一个对象移动到另一个对象，这使得我们可以在对象模型中导航，并建立对象关系（类似于网络数据模型）。在关系模型中，通过使用检索标准，SQL合并和过滤结果集，你可以查找找所需的行。标识符在对象模型中既可以是实时引用，也可以是持久的唯一标识符（称作OID）。在关系领域里，主键定义了数据集在整个数据空间中的唯一性。
对象模型中有丰富的关系集合：继承，聚合，关联，复合，依赖，以及其它。在关系模型中，可以仅使用外键来指明一种关系。我们已经对感兴趣的两个领域进行了介绍并比较了每一个领域的几个重要功能，然后将简单了解UML中关系数据模型的标注。
1.2UML数据模型Profile（特性描述）
数据模型Profile是Enterprise Architect的UML扩展来支持关系数据库建模。它包括一些定制扩展，如：表，数据库图表，表键，触发器和约束。它是一种在UML中对关系数据库建模的技术。
表和列表在UML数据Profile中是带《Table》构造型的类，它在右上角显示一个表的符号。数据库中的列用《Table》类的属性来建模。
例如：上面图型显示与客户表关联的属性。在此示例中，对象ID被定义为表的主键，还有两个列：“Name”和“Address”。注意上图例子中列的数据类型是按照原DBMS的数据类型定义的。
行为到目前为止，我们仅定义了表的逻辑（静态）结构。此外，我们将描述与列关联的行为，包括：索引，键，触发器，过程等等。行为表示为带构造型的操作。
下图显示我们讨论的表，它有一个主键约束和索引，均被定义为带构造型的操作。
注意：“OID”列上的PK标签定义了逻辑主键，而构造型操作“?PK? idx_customer00”定义了与主键实现相关联的约束和行为（即主键的行为）。
对上例进行增加，我们现在可以定义附加行为，如：触发器，约束，存储过程。见下图：
这个例子描述了下列行为:
一个主键约束（PK）;
一个外键约束（FK）;
一个索引约束（Index）;
一个触发器（Trigger）;
一个唯一性约束（Unique）;
一个存储过程（Proc）
一个有效性检查（Check）.
使用上面提供的标注，我们可以在DBMS层次上，对复杂的数据结构和行为建模。另外，UML还提供表达逻辑实体间关系的标注。
关系
UML数据建模profile定义了两个表间任意一种依赖关系。它表示为一构造型的关联并包括一组主键和外键。数据profile仍然需要一种关系一直参与到父类和子类之间，父类定义一个主键，子类实现一个建立于全部或部分父类主键基础上的外键。这种关系将被区分为：“定义的”（如果该子类外键包含所有父类主键元素）和“非定义的”（如果只包括部分主键元素）。这个关系可以包括基数性约束，以及采用成对的相关主键与外键来建模，并命名为关联角色。下图描述了使用UML对这种关系的建模。
物理模型
UML也提供一些机制来表示数据库的整体物理结构，它的内容和部署位置。我们用构造型组件来表示一个物理数据库。见下图：
一个组件表示了一个离散，可部署的实体。在物理模型中，组件可以映射到一个物理硬件（UML的节点）。对于数据库内的关系模式，我们用带《Schema》构造型的包来表示。一个表可以放置到《Schema》中来建立它在数据库中的范围和位置。
1.3从类模型到关系模型的映射
我们已经描述了所关注的两个领域和它们使用的标注，现在将我们的注意力转移到如何映射，及如何从一个领域转换到另一个领域。以下采用的策略和表达顺序是建议性的，而不是必须的。采用何种步骤和过程要根据个人的需要和环境而定。
1. 类的建模
首先我们假设从一个已经创建的类模型构建一个新的关系数据库模式。显然这是一个最容易的方向，这是因为模型一直在我们的控制之下，并且我们能根据类模型来优化这关系模型。在现实环境下，你可能需要在原有数据模型之上对类模型分层，这是更难的一种情况，具有挑战性。在这里，我们只关注第一种情况。至少类模型会记录元素的关联，继承和聚合关系。
2. 标识持久对象
建立类模型后，我们需要将类模型的元素分成需要持久性和不需要持久性两类。例如，如果我们采用“模型－视图－控制”的设计模式来设计我们的应用程序，那么只在模型部分的类将需要持久状态。
3. 假设每一个持久类映射到一个关系表
这是一个大的假设，但是它对大多数情况有用（现在先把继承的问题放一边）。在一个最简单模型中，一个来自逻辑模型的类映射到关系表的全部或一部分。这个映射的逻辑扩展是一个单独的对象（或类的实例）映射到表中单独的“行”。
4. 选择一个继承策略.
继承可能是从面向对象模型转换到关系模型过程中最容易出现问题的关系和逻辑结构。关系领域本质上是平面的，每一个实体自身完成，而对象模型常常是一个具有深度的，设计完善的类层次结构。这样深度的类模型可以有多层的继承属性和行为，运行时生成最后全功能的对象:
每一个类层次结构有一个单独对应的表，这个表包含所有元素的继承属性－因此，这个表是该层次结构中每个类的联合。例如，人，父母，孩子和孙子可能形成一个单独的类层次结构，并且每个类中的元素都会出现在相同的关系表中;
类层次结构中的每一个类有一个对应的表，该表有仅能被该类访问的属性（包括继承属
性）。例如，如果“孩子”仅仅从“人”继承而来，表将仅包含“人”和“孩子”的元素;
类层次结构中的每个类的自有属性对应一个表。例如，“孩子”将映射到一个仅带孩子属性的单个表
对每一种方法，我们有对应的案例。但是我们推荐第三种方法，因为它最简单，最容易维护和最不容易出错。第一种方法提供了运行时最佳的性能。第二种方法是第一种与第三种的折衷。第一种方法展开层次结构，在一个表里放置所有的属性，这样方便类层次结构中对类的更新和提取，但是不易于验证和维护。与“行”关联的业务规则是难以实现的，因为表中的每一行都可能被实例化为层次结构中的对象。“列”之间的依赖关系可能变得相当复杂。此外，对层次结构中任何一个类的更新将可能影响层次结构中其它每个类，如表中的列被添加，删除和修改。
第二种方法是一种折衷方案，提供了更好的封装和消除空列。可是，对父类的修改可能需要在所有子类的表中进行复制，更糟的是，有两个或多个子类的父类数据可能被冗余地存储在许多表中；如果父类的属性被修改，那么要花相当的时间去查找相关的子表，并更新受影响的行。
第三种方法精确地反映了对象模型，它将层次结构中的每一个类映射成一个独立的表。父类或子类的更新是在正确空间的局部范围内进行的。对实体的任何修改被严格限定于单个表内，因此表的维护也就相对简单。缺点是需要在运行时重构结构层次，来精确产生一个子类的状态。一个“Child”的对象可能需要一个“Person”的成员变量用于表示它的父辈。由于这两者都需要加载，两次调用数据库来初始化一个对象。随着类结构层次加深，初始化或更新一个单独对象的数据库调用次数也随之增加。
当你映射继承关系到关系模型时，理解上述要点是很重要的，这样你就选择最适合你的方案。
5. 为每一个类添加一个唯一的对象标识符
在关系和对象的领域里，需要唯一标识一个对象或实体。在对象模型中，非持久对象在运行时通常被直接引用或对象指针来标识。一旦对象被创建，我们可以用它运行时的标识符来引用它。但是，如果我们将对象写入存储空间，那么如何按需要得到完全相同的实例是一个问题。最便捷的方式是定义一个OID（对象标识符），它在关注的命名空间是被确保唯一的。根据需要，这可能发生在类，包或系统的层级上。
系统级别OID的一个例子可以是一个使用微软“guidgen”工具创建的GUID（全局唯一标识符），如{A1A68E8E-CD92-420b-BDA7-118F847B71EB}。类级别的OID可以用简单得数字实现（如：３２位计数器）。如果一个对象具有对其它对象的引用，它可以采用使用它们的OID的方法。那么，在运行时有效地将引用的对象从存储区加载到模型中。关于上述OID值的重点是它没有超出定义它为标识符的简单含义。它们仅是逻辑指针而没有其它意义。在关系模型中，情况往往是不同的。
关系模型中标识正常地用一个主键实现。主键是一个表中的一组“列”，它们合起来可以唯一地标识一个行。例如：名称和地址可以唯一地标识一个“客户”。其它实体，如：“销售员”引用“客户”，它们要实现基于“客户”主键的外键。这个方法存在的问题是：将业务信息（如客户名和地址）嵌入标识符中对我们目标的影响。设想三个或四个表全部具有基于“客户”主键的外键，对于一个需要修改客户主键（如：增加一个用户类型）的系统修改，那么既要修改客户表，也要修改与外键相关的实体，这个工作是十分巨大的。
另一方面，如果一个OID被当作主键实现，并为其它表建立外键，那么修改范围仅限于主表，并且修改的影响也因此大大减小。实际上，一个基于业务数据的主键也许会被修改。如：一个客户可以修改地址和名字，既然这样，这个变化需要被正确的传递到所有其它相关的实体，更不用提改变部分主键信息的困难。
一个OID总是引用同一个实体，而不管其它信息怎么改变。在上面的例子中，客户可以修改名称和地址，与它相关联的表不需要被修改。当把对象模型映射到关系表时，实现完全OID的标识符比采用业务联系的主键更加便捷。用OID做为主键和外键的方法将为对象提供更好的加载和更新效率，将维护服务减到最少。实际上，一个与业务相联系的主键可以替换为：
●一个唯一性约束或相关列的索引;
●嵌入类行为的业务规则;
●或将上述两种结合起来.
再次重申，是使用有意义的键还是使用OID取决于被开发系统的实际需要。
6. 映射属性到“列”
通常，我们将简单的类数据属性映射到关系表的列。例如，一个文本或数字字段可以分别表示一个人的名字和年龄，这种直接映射不会引起什么问题，只是简单地在数据库服务商
的关系模型中选择适当的，与类属性相对应的数据类型。
对复杂属性（即属性为其它对象）使用下面详细的步骤来处理关联和聚合关系。
7. 映射关联到外键
更复杂的类属性（即它们代表其它类）通常建模为关联关系。一个关联是对象间的结构关系。例如，一个人可以居住在一个地址，当这个人被建模，他会有城市，街道，邮编的属性。在对象和关系领域里，我们倾向于把这个信息当作单独的实体来构造:“地址”。在对象领域里，地址代表一个独一无二的物理对象，并可能带有一个唯一OID。在关系领域，一个地址可以是地址表中的一行，该表的主键被用作为其它实体的外键。
在这两种模型中，趋向于移动地址信息到独立实体，这有助于避免冗余数据和提高可维护性。所以对于每一个类模型中的关联，要考虑创建一个从子类到父类表的外键。
8. 映射聚合和复合
聚合和复合关系类似于关联关系，并通过“主键－外键”对来映射成表。但是，需要提醒的是：普通聚合（弱聚合）对关系建模，如：一个人住在一个或多个地址，在此例中，超过一个以上的人可能住在相同地址，如果这个人不在这里住了，与他相连的地址仍然存在。这个例子例举了关系术语中称之为“多对多的关系”，并且通常实现为一个独立的表，该表包含了从一个表格的主键到另一个表格主键的映射。
弱聚合的第二个例子是：一个实体在那里使用或排除了另一个实体的所有权。例如：一
个“人”的实体拥有一组股票，这标明这个人可能与一个“股票”表中的某些股票有关联，也可能没有关系。但是每个股票可以联系一个人，或不与任何人发生关系。如果这个人不在了，这个股票将变为“无主”的，或者被传递给下一个人。在这个关系模型中，可以通过每个股票有一个“所有者”列来实现，这个“所有者”列将存储一个人的标识符（OID）。
强聚合形式则有与之关联的完整约束。复合表明一个实体由部件组成，并且这些部件对整体有依赖关系。例如：一个人可以有很多证明文件，如护照，出生证明，驾照等。这个人的实体可以由这样的一组文件组成。如果这个人从系统里被删除，那么证明文件也要被删除，因为这些文件被映射到一个唯一个体。
如果我们暂时忽略OID，弱聚合可能使用中间表来实现（对多对多的情况）或者在一个聚合的类或表采用一个外键来实现（一对多的情况）。在多对多关系的情况下，如果父类被删除，中间表中的实体也要被删除。在一对多的情况下，如果父类被删除，外键输入（如“所有者”）必须被清除。
在复合的情况下，外键的使用是强制的，约束条件是父类删除后，部件也必须被删除。逻辑上，复合是有一种含义，部件主键形成了全部主键的一部分。例如：一个人的主键由他证明文件组成。尽管实际上是相当冗长的，但逻辑关系上为真。
9. 定义关系作用
对于每一个关联关系，可能会进一步指明关系每一个端点的角色信息。通常包含主键约束名和外键约束名。图６例示了这个概念，这在逻辑上定义两个类之间的关系。另外，可能会在作用名上标明附加约束（即{非空}）和基数性约束（即０..ｎ）。
10. 模型行为
我们现在来讨论另一个难题：是映射部分还是所有的类行为到数据库商提供的功能上，这些功能以触发器，存储过程，唯一性，数据约束和关系完整性的形式出现。一个非持久对象模型通常可以实现一种或多种语言（如Java和Ｃ++）需要的所有行为。每一个类将用公共的，保护的和私有的方式描述它被赋予的行为和职责。
不同数据库商的关系数据库通常包含不同形式的，基于SQL的可编程脚本语言，用来实现对数据的操作。最常用的例子是触发器和存储过程。当我们混合对象和关系模型，要做的决定往往是：是实现类模型中所有的业务逻辑，还是将部分的业务逻辑放在关系DBMS
中更常用而有效率的触发器和存储过程中。从完全面向对象的角度看，答案是避免使用触发器和存储过程，并且将所有行为放到类中。这样会使行为局部化，从而提供了一个更清晰的设计，简化了维护，并且提供了在不同DBMS提供商之间更好的移植性。
在现实世界，存储过程和触发器的设计目标底线可以是每秒至少执行几百次或几千次之多。如果为了追求模型的清晰，移植性，可维护性和灵活性，那么就将所有的行为放在对象方法中。
如果性能是关注的焦点，可以考虑将部分行为交给更有效的DBMS编程语言。注意到将对象模型与存储过程以安全方式集成所花的额外时间，包括远程影响和调试的问题，可能要比简单部署更高性能的硬件更多。
如前面所述，UML数据profile提供下列扩展（构造型操作），可用来对DBMS行为建模:
●主键约束（PK）;
●外键约束（FK）;
●索引约束（Index）;
●触发器（Trigger）;
●唯一性约束（Unique）;
●有效性检查（Check）.
11. 产生物理模型
在ＵＭＬ中，物理模型描述了物体如何在现实世界里部署：硬件平台，网络连接，软件，操作系统，动态连接库和其它组件。你需要生成一个物理模型来完成这个周期：从一个初始的用例或领域模型，到类模型和数据模型，最后到部署模型。通常对这个模型，你要创建一个或多个节点，这些节点可以存放数据库，并安装DBMS组件。如果数据库被分成多于一个的DBMS实例，你可以分配表的包《Schema》给单个DBMS组件来指明数据位置。
1.4总结
使用UML进行数据库建模，就象你看到的，当从对象领域映射到关系领域时，有很多要注意的问题。UML提供了这两个领域之间的桥梁。UML数据profile也是一种成功地把两个领域集成起来的优秀的扩展语言。
2.UML 教程
统一建模语言(UML)已经迅速变成建立面向对象软件的事实标准。本教程提供了Enterprise Architect支持的13种UML图的技术概览。UML 2 详细的语义解释请看新的UML 2 教程。
首先... 什么是UML?
OMG组织规范声明:
"统一建模语言(UML)是一种图形化的语言，用于软件密集系统要素的可视化、制定规范、构建对象和编写文档。UML提供了一种标准的方式来描述系统的设计图，既包括概念方面，例如业务过程和系统功能，也包括具体事务，如编程语言语句，数据库图示和可重用的软件组件。
这里着重指出的是UML是一种说明性的“语言”，而不是一种方法或程序。UML通常
用来定义软件系统与细化、编写、构造系统中的要素，是“写”设计图的语言。UML可以用不同的方式来支持软件开发方法(例如：统一软件开发过程)-但是它本身并不指定某种方法或过程。
UML 定义了下列领域的标注和语义:
- 用户交互或用例模型-描述系统和用户之间的界定和交互。在某些方面对应于一个需求模型。
- 交互或通信模型-描述系统中的对象彼此之间如何进行交互以完成工作。
- 状态或动态模型-状态图表描述随着时间变化，类所呈现的状态和条件。活动图则描述系统即将执行的工作流程。
- 逻辑或类模型- 描述构成系统的类和对象。
- 物理组件模型- 描述构成系统的软件(有时也包含硬件)。
- 物理部署模型- 描述物理架构与物理架构中组件的部署。
UML 也定义了一些扩展机制，以扩展UML符合特别需要(例如：业务过程建模的扩展)。
2.1用例模型
用例模型描述的是新系统规划的功能。它表示用户（人或机器）和系统之间交互的离散单元。该交互是一个有意义的独立单元，如：创建账户，浏览帐户信息。
每一个用例描述建立在规划系统中的功能，它可以包含另一个用例功能或用自己的行为扩展另一个用例。
一个用例描述通常包括：
●描述用例的常规注释和说明
●需求- 用例必须提供给最终用户正式的需求。如：
能更新订单"。它们都对应构造方法中建立的功能规范，并建立用例执行动作和给
系统提供值的约定。
●约束- 用例运行所遵循的正式规则和限制，它们定义了什么能做，什么不能做。
包括：
?预置条件是用例运行以前就已经发生了。如："创建订单"
须发生在"修改订单"
?后置条件是用例完成后必须为真，如："订单修改和一致性检查"。
?常量在用例的整个运行过程中始终为真，如：一个订单一直有客户号。
●情形–用例执行时各步骤正式有序的描述，或用例实例化过程中事件发生的流程。
它包含多种情形来应付特殊环境和可选择的处理方式。它们通常由文本建立和对应
于顺序图的文本表达。
●情形图- 描绘工作流的顺序图;类似于情形，但是图形化描述。
●附加属性，如实施阶段，版本号，复杂性程度，构造型和状态。
执行者
用例通常与执行者关联，执行者可以是人或机器实体，用于系统交互来执行有意义的工
作从而帮助他们完成目标。执行者参与的用例定义了它们在系统中总体的作用和动作的范围。
包含和扩展用例间的关系
一个用例可以包含另一个用例功能做为它自身正常运行的一部分。通常假设在用例运行时被包括的用例每次都会被调用。例如：在修改选定订单前，列出一份客户订单表，每次"列出订单"用例被调用执行。
一个用例可以被一个或多个其它用例包含。通过将通用的行为提炼成可以多次重复使用的用例，有助于降低功能重复级别。
通常，在特别情况下，一个用例可以扩展另一个用例的行为。例如：如果一个用户在修改一个特别类型的客户订单之前，该用户必须得到某种更高级别的许可，然后“获得许可”
顺序图
顺序图提供随时间变化，对象交互的图形化描述。通常用来表现一个用户或执行者，对象和组件，以及它们在用例执行过程中之间的交互。一个顺序图典型地表示一个单独的用例情形或事件流。
顺序图可以出色的显示文档使用情形，既可以记录早期分析的所需对象，也可以在稍后的设计阶段验证对象。它显示一个对象到另一个对象的消息流，这些消息流对应着一个类和对象支持的方法和事件。
下面顺序图例示了左侧的用户或执行者初始化事件和消息流，它们对应于用例情形。在最终模型中，对象间传递的消息变成类的操作。
执行图
用例是对所构造系统将有功能的正式描述。与用例关联的执行图用来设计元素（如：组件和类）和实现用例在新系统中的功能。这为系统设计者，客户和团队，这些实际建立系统的人，提供了高级别可跟踪能力。组件和类连接的用例列表说明了必须被组件执行的最少功能。
上图说明用例"Login"实现需求"1.01 Log On to the website"。也显示组件"Business Logic"和"ASP Pages"组件实现部分或全部"Login"功能。进一步细化可显示"Login"界面(一个网页)来实现"Login"用例。这些执行和实现连接定义了从正式需求，到用例，直至组件和界面的可跟踪能力。
2.2动态模型
动态模型用于对系统的行为随时间变化而进行的建模和描述。它支持活动图，状态图，顺序图，以及包含业务过程建模的扩展功能。
顺序图
顺序图用来显示用户，对象，界面和实体之间的交互。它提供了随时间变化，消息在对象间传递的时序图。这些图经常被放于模型用例内来图示用例情形：用户如何与系统交互，内部如何完成任务。通常这些对象用特殊构造型按钮表示，如下图的例子。对象"Login Screen"使用用户接口"User interface"图标.对象"SecurityManager"使用控制器"Controller"图标。" users"使用实体"Entity"图标。
活动图
活动图用来显示系统中不同的工作流是如何构造的，它们如何开始，以及它们从开始到
UML实验指导书 实验一用例图 (2) 实验二类图和对象图 (4) 实验三顺序图、协作图 (6) 实验四活动图 (8) 实验五状态图 (10) 实验六组件图和部署图 (11) 2011-9-1
实验一用例图 一、实验目的和要求 1．熟悉UML建模工具Visual Paradigm和Rational Rose的基本菜单及操作。 2．熟悉用例图的基本功能。 3．掌握绘制用例图的方法。 二、实验内容 1．设计和实现某学校的网上选课系统的用例图。 2．网上选择系统的问题描述如下： 某学校的网上选课系统主要包括如下功能：管理员通过系统管理界面进入，建立本学期要开的各种课程、将课程信息保存在数据库中并可以对课程进行改动和删除。学生通过客户机浏览器根据学号和密码进入选课界面，在这里学生可以进行三种操作：查询已选课程、选课以及付费。同样，通过业务层，这些操作结果存入数据库中。 本系统拟使用Java语言通过三层模型实现：数据核心层、业务逻辑层和接入层。数据核心层包括对于数据库的操作；业务逻辑层作为中间层对用户输入进行逻辑处理，在映射到相应的数据层操作；接入层包括用户界面、系统登录界面、管理界面、用户选课界面等。 三、实验要求 1．对本系统中的参与者、用例进行分析，并绘制用例图。 2．写出添加课程、选课的用例详述。 3．按要求认真填写实验报告。 下面是系统中出现的一些事件流。 添加课程事件流： a)管理员选择进入管理界面，用例开始。 b)系统提示输入管理员密码。 c)管理员输入密码。 d)系统验证密码。 A1：密码错误 e)进入管理界面，系统显示目前所建立的全部课程信息。 f)管理员选择添加课程。 g)系统提示输入新课程信息。 h)管理员输入信息。 i)系统验证是否和已有课程冲突。
《统一建模语言》实验指导书 软件学院软件工程系 李林林 2009年3月
目次 实验一rose的使用 (3) 实验二用例图 (4) 实验三类图、对象图 (7) 实验四序列图与协作图 (8) 实验五状态图 (12) 实验六活动图 (14) 实验七包图、构件图和部署图 (15) 实验八运用UML进行系统分析与设计——图书管理系统的分析与设计 (16)
实验一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
《面向对象分析与设计UML》 实验报告 学号：180108213 姓名：庞志伟 班级：08级软件2班 指导老师：姚宇峰
实验及作业一 一、实验目的 了解软件工程等基础知识，为后续的统一建模语言UML知识的学习做好准备工作。 二、实验设备与环境 装有Visio、RathionalRose的计算机。 三、实验内容 1、复习阐述“软件工程开发模型”的相关概念，并分析各种模型的优缺点，写成实验报告。 2、熟悉UML软件设计工具Visio、Rational Rose的安装及环境 四、实验过程及结果 1、软件工程开发模型有（1）瀑布模型，（2）原型模型，（3）螺旋模型，（4）喷泉模型（1）瀑布模型 将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。 优点： 1）为项目提供了按阶段划分的检瀑布模型查点。 2）当前一阶段完成后，您只需要去关注后续阶段。 3）可在迭代模型中应用瀑布模型。 缺点： 1）在项目各个阶段之间极少有反馈。 2）只有在项目生命周期的后期才能看到结果。 3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。 （2）原型模型 原型模型又称快速原型，它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。 优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。
可视化建模与UML 实 验 指 导 井大电信学院 2015.03
目录 实验一常用建模软件 (3) 实验二需求定义与陈述 (4) 实验三用例建模 (8) 实验四类图（与对象图）建模 (10) 实验五UML静态模型分析 (11) 实验六交互建模（顺序图与协作图） (14) 实验七行为建模（状态图和活动图） (16) 实验八* 构件图和部署图建模 (20) 实验九* 交互概述图 (22) 实验十* 设计建模实例与分析 (27) 实验十一* 数据库建模实例与分析 (29)
实验一常用建模软件的使用 【实验目的】 1.熟悉常用UML建模工具。 2.熟练掌握Rational Rose的基本操作 3.掌握UML规则和相关机制。 4.掌握UML的可见性规则和构造型的作用。 【实验性质】 验证性实验 【实验环境要求】 Pentium II以上微机，Windows2000以上操作系统，Rational Rose2003，Microsoft Visio,网络。 【实验内容和步骤】 一、安装Rational Rose2003或其它任意一种UML建模工具。本项内容实验者根据情况选择并在实验课外完成。 二、练习使用建模工具建立各种UML图形，并对图形进行相应编辑和修改。认识各种UML关系及可见性符号，并用工具表示出来。 【分析与讨论】 1.总结UML在软件工程中的作用以及使用UML建模的必要性。 2.比较不同建模工具。 【实验导读】 关于Rational Rose2003的安装。Rational Rose的安装比较麻烦，通过安装Rational Rose2003，并在安装过程中，发现一些问题，解决和理解
介绍 顺序图也称序列图，主要用来系统中的某个流程的详细步骤。顺序图能够给出流程中一系列对象的交互顺序。通过顺序图可以让我们更好的了解如何实现某个用例 的方法。我们知道用例图用来描述系统的功能需求。而顺序图清晰的描述了某个用例也就是系统功能的的实现方法。 详解 在顺序图中包含的元素： 对象：用来标识流程中的详细步骤中的对象。 活动条：用来标识当前对象是活动的，如果想表示某个对象是活动的，那么必须使用一个虚线+活动图的形式来构建。 例如我们现在要标示一个简单的做公交车的刷卡流程：
IC卡刷卡 操作。 相关解释说明： 公交卡,首先放在刷卡终端上，终端读取卡中的余额信息，然后刷卡终端与终端中的扣款程序对象交互，扣款程序根据读取的余额信息，与刷卡终端中的固定刷卡 金额对比，如果当前IC卡的余额大雨刷卡终端的固定金额则,扣除金额，并且返回一个消息，提示刷卡成功的操作。 途中的实线表示调用被调用对象的方法，虚线表示当被调用对象执行成功后，返回的虚线上表示返回值的逻辑名称，这样可以提高了可读性。 在公交卡与活动条之间，应有一个虚线链接。 在上图中我们使用了活动条，活动条作为生命线的一部分。我们并没有定义对象的创建和销毁，因此我们来看UML建模语言提供的描述对象的创建与销毁实例。
上图中的X符号的图标代表的时候对象的销毁。创建对象通过new来创建，上图中，我用中文描述“创建对象”来完成对象的创建，那么在生命线下的的X符号代 表销毁对象，从内存中移除对象。当然这个对象的销毁对不同的开发语言有这不同的处理方式。C++中的销毁对象，必须调用析构函数来销毁对象。C#与JAVA 语言中 则只是说明当前需要销毁的对象没有被其他的对象引用，那么这类语言编译器提供垃圾回收器来完成回收。 注意：当某个对象引用了另外一个对象，该对象有责任销毁被引用对象并且必须显示销毁该被引用对象时，那么必须要显示的发送被引用对象销毁的通知消息。白 话文来说就是显示的调用被引用对象的销毁方法。 顺序途中的同步与异步。 顺序图中的同步与异步与我们平时书写代码中的同步与异步的解释意思差不多。这里不过多解释，通过图例说明：
UML 实验指导书
目录 实验一UML建模基础 (3) 实验二用例图 (4) 实验三UML类图 (9) 实验四对象图 (13) 实验五包图 (14) 实验六状态图 (17) 实验七活动图 (21) 实验八时序图与协作图 (22) 实验九组件图 (26)
实验一UML建模基础 [实验目的和要求] 1、熟悉UML建模工具Rational Rose的基本菜单及操作。 2、掌握UML的三大组成部分及各部分作用。 3、掌握UML规则和相关机制。 4、掌握UML的可见性规则和构造型的作用。 [实验内容和步骤] 1、练习使用建模工具建立各种UML图形，并对图形进行相应编辑 和修改。 2、认识各种UML关系及可见性符号，并用工具表示出来。 [分析与讨论] １、总结UML在软件工程中的作用以及使用UML建模的必要性。
实验二用例图 [实验目的和要求] １、掌握用例的概念。 ２、掌握UML用例图的组成、作用以及使用场合。 ３、掌握用例与用例之间的各种关系。 ４、学习针对具体场景使用用例图进行分析说明的方法。 ５、掌握用例描述的概念和基本结构，以及用例描述的作用。 [实验内容和步骤] １、什么是用例，什么是场景？用例和场景之间的关系是怎样的？ 用例是用户希望系统具备的功能，它定义了系统的行为特征。 ２、用例图中有哪些组成元素？在UML中是如何表示的？ 用例图的组成元素有参与者、用例、关系、系统。 ３、用例与用例之间的包含关系、扩展关系和泛化关系各代表什么含义？它们之间有何区别？对以上三种关系各举一例，画出用 例图，并进行说明。 用例与用例之间的包含关系实际上就是面向对象语言中对象之间的调用关系，扩展关系实际上就是一种依赖的关系，泛化关系实际上就是面向对象中的继承关系。 ４、为了满足物业中介行业的信息化要求，甲公司基于详尽的需求调研与分析，准备研发一套符合市场需要的、实用的信息管理 系统。主要将实现客户资料信息管理、客户委托（出租、出售、租赁、购买）信息管理、业务线索生成与管理、房源状态自动 更新、权限管理、到期用户管理、房源组合查询等功能。该公 司小王，通过多次的与潜在客户的交流与沟通，完成了最初的 用例模型的开发，下是一个用例模型的局部：
档编号：Personnel Management’08_Development_00 版本号：1.0 文档名称：用户手册 项目名称：图书管理系统 项目负责人：*** 编写：**** 校对：**** 审核：**** 批准：**** 开发单位：软件工程开发小组
1引言 (2) 1.1编写目的 (2) 1.2背景 (2) 1.3定义 (2) 1.4参考资料 (2) 2用途 (2) 2.1功能 (2) 2.2性能 (3) 2.2.1精度 (3) 2.2.2时间特性 (3) 2.2.3灵活性 (3) 2.3安全保密 (3) 3运行环境 (3) 3.1硬设备 (3) 3.2支持软件 (3) 3.3数据结构 (4) 4使用过程 (4) 4.1安装与初始化 (4) 4.2输入 (4) 4.2.1输入数据的现实背景 (4) 4.2.2输入格式 (4) 4.2.3输入举例 (5) 4.3输出对每项输出作出说明 (5) 4.3.1输出数据的现实背景 (5) 4.3.2输出格式 (5) 4.3.3输出举例 (5) 4.4文卷查询 (6) 4.5出错处理和恢复 (6)
1引言 1.1编写目的 在完成软件开发工作，结合《详细设计说明书》，并分别与软件使用者和程序员进行了较为深入地探讨和分析的基础上，项目小组（系统分析员）提出了这份用户手册。 此概要用户手册介绍了《图书管理系统》软件的功能分配，模块划分，程序的总体结构，输入输出和接口设计，运行设计，数据结构设计及出错设计等方面作了全面的概括性的说明，为用户使用本软件提供了便利。 1.2背景 说明： （1）本系统的名称是：图书管理系统 （2）本项目的任务提出者是某高校，开发者是软件项目管理小组，用户是某企业人事及相关部门。 1.3参考资料 列出有用的参考资料，如： [1]软件工程开发小组, 《<图书管理系统>需求规格说明书》, 2014. [2]软件工程开发小组, 《<图书管理系统>概要设计说明书》, 2014. [3]软件工程开发小组，《<图书管理系统>详细设计说明书》，2014. [4]软件工程开发小组，《<图书管理系统>测试分析报告》，2014. [5]朱作付, 《软件工程》, 科学出版社, 2005. [6]郑人杰, 殷人昆, 陶永雷, 《实用软件工程》, 清华大学出版社, 1997. [7]卫红春, 《软件工程概论》, 清华大学出版社, 2007. 2用途 2.1功能 本软件主要是为了帮助学校相关职能部门对图书信息进行高效的管理和维护，主要的功能如下： a.图书信息的增加、修改、删除，支持多种途径的数据录入。 b.图书信息按各种条件查询，可在操作界面输出列表。
实验二用Visio绘制UML图 1.1.实验基本目的 本实验练习使用Microsoft Visio软件绘制UML图。 1.2.实验原理 UML是一种可视化建模语言，由视图（view）、图（diagram）、模型元素（model element）和通用机制（general mechanism）等几个部分组成。其中视图表示系统的各个方面，由多个图构成。每个图使用了多个模型元素。在此基础上，通用机制为图做进一步补充说明，如：注释、元素的语义说明。 图表绘制软件Visio可以用来绘制UML图。 1.3.实验设备 1.3.1.硬件： PC机：1台，连入局域网。 1.3. 2.软件： Microsoft Visio 2007 1.4.实验的基本内容及要求 用Visio绘制UML用例图、类图、顺序图，并掌握绘图技能。 1.5.实验内容 根据教材149页7.7题描述的问题域，完成以下题目： 1. 识别该系统中的用例并绘制用例图； 2. 为该系统绘制概念类图； 3. 针对选课用例绘制顺序图。 注：如果你的用例分析将第一次选课和第二次选课作为两个用例，绘制这两个用例的顺序图。
1.6.实验步骤 1.6.1.建立“UML模型图”文件 启动Visio，选择“软件和数据库”绘图类型中的“UML模型图”（见图1）。保存该文件。 图1 启动Visio中的UML模型图 1.6. 2.模型资源管理器 新建的UML模型文件的界面中有一个“模型资源管理器”（如图2所示），如果没有此窗口，可选择菜单“UML”->“视图”->“模型资源管理器”选项打开此窗口。 图2 模型资源管理器 所建立的UML模型均体现在模型资源管理器中。右键单击“UML系统1”->“模型”可以在弹出窗口中建立新的系统模型，如“动态模型”。 在模型下可以用“包”来组织系统中的UML图，右键单击包名（如：顶层包）可以在该包下新建“包”或者“UML图”。 在模型资源管理器中可以对模型、包、UML图以及各种UML图形元素进行重命名（单击右键->重命名）。 可以从模型资源管理器中将已存在于模型中的UML图形元素拖曳到绘图区，这样已
XXXXX学校图书馆 读者手册
编委会主编： 副主编： 编委：
图书馆网站：https://www.doczj.com/doc/e13117680.html,/微信图书馆：XXXXX 微图图标
目录 一、XXXXX学校图书馆概况 （一）基本概况 （二）馆舍与设施 二、图书馆开放时间 三、图书馆分布 四、电子资源介绍 （一）超星电子图书数据库 （二）CNKI中国知网数据库 （三）万方数据库 五、图书馆规章制度 （一）读者入馆须知 （二）借阅管理细则 （三）书刊、设备及设施遗失、损坏赔偿办法六、图书馆基本知识 （一）《中国图书馆图书分类法》简表 （二）分类号（索书号） （三）馆藏图书排列 七、图书馆使用常见问题解答 （一）关于借阅证问题 （二）关于书刊借阅问题 （三）图书馆常用概念
一、XXXXX学校图书馆概况 （一）基本概况 XXXXX学校图书馆由XX图书馆、XX图书馆2个图书馆组成。馆舍总面积达XX万平方米，现有阅览座位近XX个，电子阅览及检索终端XXX台。设施先进，环境舒适。 经过十多年的建设与发展，馆藏纸质图书总量为XX万册：其中，中文纸质图书XX万册，外文纸质图书XX万册。纸质期刊XX种，报纸XXX种。数字资源有超星电子图书XXX万册、中国知网数据库、万方数据库、超星学术视频、万方名师讲坛视频等，存储容量为XXXXTB。馆藏文献以软件工程、互联网工程、物联网工程、电子信息工程、信息安全、云计算、艺术工程、游戏与动漫设计制作、电子商务、市场营销、财务管理和信息服务等专业为主。逐步形成了内容丰富，结构合理的文献信息资源保障体系。 遵照“读者第一，服务育人”的宗旨，图书馆推行藏借阅一体、开架借阅等超市化管理模式，实行统一门禁，设有总服务台，读者带书包进馆可随意进入各阅览区。书刊阅览每周向读者开放90小时以上，网上资源服务全天开放。 （二）馆舍与设施 XXXXX学校图书馆在两个校区分别有1个独立馆舍，共计XX 万平方米，提供近XX个阅览座位。两个校区的图书馆均具有完善的网络设施，全馆实现无线网覆盖。数字图书馆全天候为读者服务，存储容量为XXTB。
1.Session 当一名客户将一张ATM卡片插入机器时，一个Session开始，ATM系统读卡(如果客户执行非法操作或卡片损坏，卡片将被退出，同时屏幕将显示出错信息，而被Session异常中断)。进行验证客户密码的登录功能。客户成功登录系统后，可以选择一种或多种操作，直至退卡。如果客户输入五次无效的PIN，则Session 被异常中断，ATM卡将被吞掉。 其顺序图如下所示：
2.Task Task是一种抽象的用例，表示所有类型的处理所共有的行为，Task的具体类型按照适当的方式执行一定的操作。根据Task(存款、取款，转帐，查询，更改密码)的事件流描述给出具体的处理。 其顺序图如下：
3.Deposit 插入用户的银行卡后，根据系统界面显示输入密码，由系统判断该帐户是否有效（帐户密码是否正确），若密码输入不正确，则再次显示让用户输入密码，若3次输入的密码均不正确，系统自动退出服务，若密码输入正确，则系统进入选择服务类型界面，选择存款业务，系统确认存款请求以后，系统界面进入请放入存款界面，然后用户将存款放入存款口，系统提示点钞机进行点钞，点钞完毕后，系统记录存款操作并更新余额，系统界面显示存款完毕，然后系统界面进入是否选择继续服务界面，用户点击否，则系统退出银行卡并提示用户取卡，用户取走卡后，存款业务完成。 存款操作的顺序图如下：
4.WithDraw 插入用户的银行卡，并根据系统界面显示输入密码，由系统判断该帐户是否有效（帐户密码是否正确），若密码输入不正确，则再次显示让用户输入密码，若3次输入的密码均不正确，系统自动退出服务，若密码输入正确，则系统进入选择服务类型界面，然后系统根据服务类型进行相应操作，若选择取款操作，系统确认取款请求以后，会询问取款数额，系统界面显示输入数额请求，用户输入取款数额，系统接到信息后发出确认取款请求，用户选择确认，系统选择确认后会向点钞机发出钞请求，然后点钞机出钞，系统向用户发出去钞请求，用户取钞以后，系统记录此次取款并自动计算余额，更新帐户信息，然后系统界面进入是否选择继续服务界面，用户点击否，然后系统退出银行卡并提醒用户取卡，用户取走银行卡，至此，取款业务完成。 取款操作顺序图如下：
目录 实验一用例图及进度安排 (2) 实验二活动图 (7) 实验三状态图 (15) 实验四类 (27) 实验五类的关系 (37) 实验六、七交互图 (43) 实验八、九对象图和包 (53) 实验十、十一组件图和部署图 (55) 实验十二正向工程 (62)
实验一用例图及进度安排 一、实验目的 1．熟悉用例图的基本功能和使用方法。 2．掌握如何使用建模工具绘制活动图方法。 3．学习使用Microsoft Project对题目进行进度安排。 二、实验器材 1．计算机一台。 2．Rational Rose 工具软件。 三、实验内容 根据图书管理系统开发要求，在完成对系统的需求建模，得到用例模型后，应针对每个用例进行业务分析，说明其具体的业务流程，现系统分析部指派您完成该项任务。要求：对其中主要功能的用例书写书面用例。 四、实验步骤 书写“删除读者信息”用例的书面用例。一般应包含以下信息： （1）管理员在录入界面，输入待删除的读者名； （2）“业务逻辑”组件在数据库中，查找待删除的读者名； （3）如果不存在，则显示出错信息，返回步骤（1），如果存在则继续； （4）“业务逻辑”组件判断“待删除的读者”是否可以删除； （5）如果不可以，则显示出错信息，返回步骤（8），如果可以则继续； （6）在数据库中，删除相关信息； （7）显示删除成功信息； （8）结束。 分析: 在图书管理系统中,管理员首先登录系统,系统验证通过后,管理方可向系统查询数据,在查询后,系统会给出提示,有没有找到相关的数据,管理员根据系统查询的返回结果,进行下一步的操作,就是删除读者,在删除的过程中,系统会对查询得到的结果判断该记录是否可以删除,若可以删除,则给删除提示,若不能删除,也给相关的提示信息。 绘图步骤: (1)在用例图上双击main,出现如图1.1所示,为绘制用例图做好准备。
60.日本机械设计手册(中文版) 61.《新编形状和位置公差标注读解》标准出版社 62.图说机械制图，形象生动，希望对大家有用 63.螺旋锥齿轮设计与加工 64.气动手册 65.公差配合和测量技术ppt、 66.《玩具器具.机械结构.自动装置》 67.《汽车标准件手册》PDF有书签 68.《机械机构精确度》PDF 69.机构设计实用构思图册 70.《机械设计实用机构与装置图册》清晰/很有价值的参考图册，很多实例 71.弯头技术手册 72.液压与气动设备维修问答（机械工业出版社） 73.《实用液压机械故障排除与修理大全》 74.液压系统设计图集（周士昌）机械工业出版社 75.华中科技大学液压与液力传动课件 76.机械77.常用机械零件及机构图册 77.精度基础(韦恩.R.穆尔）国防工业出版社 78.装配车间设计（配以事例，很好的资料） 79. 精密机械零件与部件 80.《农业机械设计手册》（上下册）中国工业出版社机械零件与部件 81.动力工程师手册（机械工业出版社1999年出版） 82.《组合机床设计参考图册》.pdf大连组合机床研究所编 83.《飞机结构设计》 84.《机械创新设计基础》 85.《公差与配合图解手册》 86.《机械结构合理设计图册》 87.动画：制图与思维 88.《飞机结构设计》国防工业出版社 89.刀具设计原理与计算PDF 90.《刀具设计手册》机械工业出版社出版 91.齿轮变位[日]仙波正荘著(pdf) 92.《减速器设计选用手册》PDG,PDF+书签 93.非圆齿轮及非匀速比传动——机械工业出版社（pdf） 94.《机械无级变速器》PDG+PDF 95.2000年以来剃齿刀论文汇总（63篇） 96. 结构设计工艺手册 97. 现代机械创新产品分析与设计 98.液压气动系统设计手册 99.《机械设计》（第七版）高等教育出版社 100.《机器设计》[PDF+书签]交通大学出版社 101.润滑技术手册 102.现代液压技术应用220例(PDF扫描版) 103.常用压力容器手册（机械工业出版社）
便利店营运管理手册 便利店属于零售业态的一种，也是个商品密集的行业，如何让众多的员工都能按照同一个标准、同一个规范来工作，从而提高我们的工作效率，提升便利店（也称便利超市）的营业额，成为所有门店管理人员的一个重要课题。 然而，便利店之所以能够在当今成为主流业态，正式在于它的先进性，它的专业化、简单化和规范化。通过一个系统的规范，一个全面的标准，经过专门的培训，人人都能掌握，店店都能复制，从而能够快速地扩大我们的规模，形成强大的连锁体系，这正是我们编制这套规范手册的目的。 便利店是最具竞争力的零售业态，如果说连锁便利店、百货商场是商品销售的主力部队和正规军，那么便利店就是机动部队和游击队。资料调查显示，城市消费者平均一星期去一次仓储百货，一天去一次综合超市，却随时可能光顾便利店。便利店以其资金周转夏迅速，服务项目更灵活，商品销售更针对性，营业时间更长等诸多优点，伊然已经走出了零售业的辅助位置，取得了综合超市、商场百货、便利店三分天下的地位。 "麻雀虽小，五脏俱全。便利店是我国市场经济发展的产物，吸取了国外的经验与模式，要想经营好一家成功的便利店，从选址、装修、进货、布局、服务上都妥下很大工夫，木手册详细地介绍了成功经营便利店的的各种流程和事实要点?希望通过本手册可以使您在便利店的经营管理中得心应手，事半功倍。 愿广大的便利连锁门店能在规范中迅速拓展。 便利店营运管理手册目录 第一章便利店的现状和定位分析 第一节便利店的开店注意要点（上） 第二节便利店的开店注意要点（下） 第二章便利店营运常用术语规范 第三章营运部组织架构及工作职责
第一节营运部组织构架图 第二节营运督导部的工作职责 第三节新店筹备部的工作职责 第四节门店营运岗位职责 1、店长岗位职责 2、门店助理岗位职责 3、门店出纳岗位职责 4、门店主管岗位职责 第四章营运管理规范 第一节营运督导巡场管理规定 第二节门店考勤制度 第三节门店卫生管理制度 第四节晨会（晚会）制度 第五节设备维护管理规范 第六节价签管理规范 第七节促销员行为管理规范 第八节门店值班制度 第九节每日每周每月报表制度 【章商品管理规范 第一节商品管理规范 1、便利店条形码管理规范 2、商品AB（分类管理规范 第二节商品订货管理 1、门店定货作业程序 2、烟草购销作业程序 3、商品屯货管理规定第三节商品收获管理 1、门店商品收货程序 2、商品收货标准规范 第四节日常商品管理
饮料销售机UML顺序图文档 引言 本文档为饮料销售机设计过程中的UML顺序图文档，编写成员为开发成员，目的是为了方便后续的开发更顺利并且便利的开展，了解系统功能顺序，对系统有一个更加直观的功能框架。 饮料销售机分析 在自动饮料售货机的“买饮料”场景中，假设饮料销售机有3个部分：前端（front）、钱币记录仪（register）以及分配器（dispenser）。 前端负责：接受顾客的选购和现钞；显示诸如Out of selection（所选饮料已售完）和User correct change（使用合适零钱）的信息；从记录仪接收找回的零钱并返还给顾客；返还现钞；从分配器接收一罐饮料并把它交给顾客。 钱币记录仪负责：从前端获取顾客输入的信息（即选购的饮料的种类和现钞）；更新现钞存储；如果缺少零钱将不让系统服务并在前端显示没有零钱；若零钱充足一切正常，找零钱。 分配器负责：检查选购的饮料是否还有货；分发一罐饮料。 类图描述： （注：该图只提供参考，参数和返回值可自行定义，方法也可以增加） UML顺序图 在饮料售货机购买饮料的所有情况中，都需要顾客往前端放入金钱，由钱币记录仪判定钞票面额。 1、理想状态下买饮料（购买成功且不用找零） 在理想状态下，顺序如下： 1、顾客放入现钞inputMoney（）； 2、前端接收现钞并将现钞传给钱币记录仪accept（）； 3、钱币记录仪对现钞面额进行判断getCustomerInput（）； 4、钱币记录仪根据现钞面额给分配器发送消息检查该面额可购买的饮料 checkForSoda（）； 5、分配器向前端返回可购买饮料信息returnSodaFree（）； 6、前端将可购买饮料显示给顾客displayPrompt（）； 7、顾客选择饮料chooseSoda（）； 8、前端将结果给分配器sendChooseToDis（）； 9、分配器检查是否有该饮料checkAvailability（）； 10、分配器向前端释放饮料releaseSoda（）； 11、前端接收饮料并释放出来receiveSoda（）； 12、购买结束 顺序图如下: 2、顾客要买的饮料售完 在此情况下，顺序如下： 1、顾客放入现钞inputMoney（）； 2、前端接收现钞并将现钞传给钱币记录仪accept（）； 3、钱币记录仪对现钞面额进行判断getCustomerInput（）； 4、钱币记录仪根据现钞面额给分配器发送消息检查该面额可购买的饮料 checkForSoda（）；
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是指当某个人与系统进行互动时发生的情况。下面是一个医院门诊部的情节。 “一个病人打电话给门诊部预约一年一次的身体检查。接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录。”
UML及其工具实验指导书 实验一熟悉UML开发工具Microsoft Visio 2007 【实验目的】 熟悉UML开发工具Microsoft Visio 2007。 【实验要求】 1．熟悉Visio的UML建模绘图界面。 2．通过绘制类图学习Visio的使用方法。 3．通过绘制对象图学习Visio的使用方法。 4．通过绘制顺序图学习Visio的使用方法。 【实验步骤】 一．熟悉Visio的UML建模绘图界面 1．进入Visio的UML建模绘图界面 通过“开始”|“程序”，运行Microsoft Office Visio 2007，出现Microsoft Visio界面。在左侧的“类别”区域中单击“软件”，然后在右侧的“模板”中单击“UML模型图”，则进入Visio的UML建模绘图界面。 2．熟悉UML建模绘图界面 在Visio的UML建模绘图界面中，最大的白色区域就是绘图区。左上方的“形状”窗口就是Visio的UML元素调板，它由很多的标签页组成。每个标签页提供了一个特定的UML 图标。左下方的“模型资源管理器”就是Visio的字典，字典就是所创建的所有元素及其属性的记录的集合。当Visio打开并准备开始UML绘图的时候，“UML静态结构”标签页就会激活，我们就可以创建类图和对象图了。 二．绘制类图 下面我们使用Visio来绘制一个如图1所示的行星系统的类模型。 图1 一个行星系统的类图 1．从“UML静态结构”标签页中选择“类”图标并把它拖放到绘图区中。双击绘图区
中的类图标，出现“UML类属性”窗口。在“名称”字段中输入“PlanetarySystem”来重新命名这个类。单击“确定”按钮回到绘图界面。我们可以通过控制工具栏中“缩放”按钮的显示比例，使界面中的类图标显示合适的大小。采用同样的方法添加Planet类。在“模型资源管理器”中反映出了增加的新类。 2．下面我们为Planet类添加两个属性和一个操作，并把它设置为一个抽象类。 在Planet类上双击打开“UML 类属性”对话框。选中“IsAbstract”复选框，然后，从左边的“类别”区域选择“特性”，在右边的对话框中打开“特性”表。单击“新建”按钮，则在“特性”表中添加了一行，在“特性”表项中输入diameter。采用同样的方式加入distanceFromStar属性。 然后从“类别”区域选择“操作”，打开“操作”表，单击“新建”按钮，则在“操作”表中添加了一行，在“操作”表项中输入“receiveLight”。单击“确定”按钮，赋予抽象类Planet相应的属性和操作。 3．注意每个属性左边的减号和每个操作左边的加号，它们表示可见性。为了使图显得比较简单，我们可以在图中去掉它们。只需要在Planet类上右击，打开弹出式菜单，选择“形状显示选项”，打开“UML 形状显示选项”对话框。去掉“可见性”复选框，单击“确定”按钮，则Planet类的属性和操作前面不再显示可见性。 4．我们把其他的类拖拽到大图中，然后添加组成关系。 首先是组成关系。从“UML静态结构”标签页中把“聚合”图标拖拽到绘图区，实心菱形一端连接到PlanetarySystem，另一端（尾端）连接到Star。 在图中，我们可以看到组成关系的每一段都有多重关系、可见性和缺省名。为了在图中去掉缺省名和可见性，在组成关系上右击，在弹出菜单中选择“形状显示选项”。这次，在“UML 形状显示选项”对话框中，去掉“第一个端名”、“第二个端名”和“端的可见性”选项，单击“确定”按钮。 现在我们来关注一下Star类的多重关系。双击组成关系图标，打开“UML关联属性”对话框。在“关联端”表格中，选择“结束2”一行“多重性”列的单元格。单击这个单元格中的下拉列表框，显示出“结束2”的可能多重性关系的一个列表。选择“1”并单击“确定”按钮，我们将在图中得到所选多重性的表示。 采用同样的方式拖拽“聚合”图标，先把菱形箭头的一端连在“PlanetarySystem”，然后再把尾端连接到Planet类，并进行多重性等相关设置。 5．向图中添加继承关系。 从“UML静态结构”标签页中将“泛化”符号拖拽到绘图区，把三角形的一端连接到Planet，尾端连接到HabitablePlanet。重复拖拽一个“泛化”符号，把三角形的一端连接到Planet，尾段连接到NonHabitablePlanet。完成这些操作后，绘图区中就是完整的类图。 三．绘制对象图 下面我们使用Visio绘制一个如图2所示的Earth和Sun的对象模型。 图2 Earth和Sun的对象图 1．在“模型资源管理器”中“顶层包”的文件夹上右击，从弹出菜单中选择“新建”|“静态结构图”，则创建并打开了一个新的静态结构图。从“形状”的“UML 静态结构”标签页中选择“对象”图标，拖拽到绘图区。
SY-023 UML 实验指导书 吴丽君编 黑龙江工程学院计算机科学与技术系 2011年8月·哈尔滨
实验一：用例图设计 一、实验目的 1. 了解USE CASE图的基本用法； 2.掌握UML中用例图的建立方法； 3. 掌握用例的描述方法。 二、实验仪器设备、材料 1.设备：计算机。 2.地点：机房。 三、实验要求： 1. 一台自动售货机能提供6种不同的饮料，售货机上有6个不同的按钮，分别对应这6种不同的饮料，顾客通过这些按钮选择不同的饮料。售货机有一个硬币槽和找零槽，分别用来收钱和找钱。现在为这个系统设计一个用例图。 2.现有一个产品销售系统，其总体需求如下： 系统允许管理员生成存货清单报告。 管理员可以更新存货清单。 销售员记录正常的销售情况。 交易可以使用信用卡或支票，系统需要对其进行验证。 每次交易后都需要更新存货清单。 分析其总体需求，并绘制出其用例图。 3.登录一个网上酒店管理系统，根据其客人预订房间流程，描述系统的“预订房间”用例。 四、实验内容与步骤 1、了解USE CASE图的基本用法。 2、使用USE CASE图进行问题域的分析，分析总体需求。 3、绘制USE CASE图。 4、描述用例。 5、撰写实验报告。
实验二：类图设计 一、实验目的 1. 了解类图的基本用法； 2. 掌握类图建模技术； 二、实验仪器设备、材料 1.设备：计算机。 2.地点：机房。 三、实验要求： 1. 在订货管理系统中，识别出的类包括：Order, Customer, OrderLine, Corporate Customer,Personal Customer, Employee和Product，其中，Order 表示订单，它的主要属性包括收到日期，是否已缴纳预付款，订单数量和价格，主要的方法为下单(dispatch)。Customer表示客户，主要分为公司客户Corporate Customer和个人客户Personal Customer两类。每一个订单Order包括多个OrderLine，OrderLine的主要属性为quantity和price。每个 OrderLine包括至少一件产品Product，每种产品可以在多个OrderLine中出现。每个职员Employee负责多个公司客户，每个公司客户只能由一名职员负责。 绘制订货管理系统的类图。 2.创建一个类图，下面给出创建类图所需的信息。 学生（Student）可以是在校生（undergraduate）或者毕业生（graduate）。 在校生可以是助教（tutor）的一种。 一名助教指导一名学生。 教师和教授属于不同级别的教员。 一名教师助理可以协助一名教师和一名教授，一名教师只能有一名教师助理，一名教授可以有5名教师助理。 教师助理是毕业生。 创建类图的步骤如下： （1）将学生可以是在校生或者毕业生建模为3个类：Student、UnderGraduate和Graduate，其中，后两个类是Student类的子类。 （2）为“在校生可以是助教的一种”建立模型，即建立UnderGraduate 类的另一个超类Tutor。
Word 书籍排版完全手册 2009-11-22 22:04:58| 分类：默认分类| 标签：|字号大中小订阅 一提到书籍的排版制作，也许有人会说只有PageMaker 或飞腾之类的软件才是专门用于排版书籍、制作海报的软件。其实并非如此，我们完全可以利用Word ，通过不很复杂的操作来达到专业出版书籍的排版要求。下面就用一个实例来向大家介绍如何利用Word 制作一本具有专业水准的书籍。本文以Word 2007 为操作环境，也同样适用于Word 2000 、Word 2003 版本，只是界面稍有不同而已。在学习排版之前，一定要准备好用来操作的文本内容的电子文稿并保存到磁盘上，并且要足够长，即要具备能够排出若干页的文字容量。 一、排版前的准备工作 1. 书籍排版的基本术语 要想制作出具有专业水准的书籍，首先必须了解一些相亲的基本术语，以及书籍排版中的一些特殊规定，这样才能保证在接下来的工作中，按照这些规定制作出符合规范的书籍。 （1 ）开本 “ 开本” 是指将整张纸裁开成为若干等分的份数，用来表明书本的大小。如经常看到的某本书是16 开本、32 开本等，即是将整张纸裁成16 等分、32 等分。 （2 ）扉页 在书籍中，扉页是指在封面之后第一页，印着书名、著者、出版日期等内容。 （3 ）版心 版心是指书刊幅面除去周围白边，放置正文和图片等内容的中间部份，也就是排版范围。 （4 ）版面 版面是指书刊每一页上的文字、插图等的排列方式。 （5 ）页眉和页脚 页眉是指在每一页正文顶端出现的相对固定的文字、图片或符号；页脚则是出现在每一页的底端的有关信息，如页码、页数、日期等。页眉可以设置成全部一样，也可以设置成奇偶页不同。 2. 导入文本 启动Word 2007 自动新建一个文档，接着将已经录入的书籍文字内容导入到这个新建文件中来（一般是由多人分章节录入的，要同时将多个文档内容导入），具体操作方法是单击功能区的“ 插入” 选项卡，然后在“ 文本” 区单击“ 对象” 右侧的下拉按钮，再选择下拉列表中的“ 文件中的文字” 选项，随即打开“ 插入文件” 对话框。在其中选择文件的保存位置、选定多个文件，再单击“ 插入” 按钮，将选定文件的内容插入到新文件中。插入后可能会打乱顺序，可利
1.1跟我学UML建模工具StarUML（第11部分）——应用StarUML创建顺序图的创建示例 1.1.1UML动态建模相关技术及应用 1、动态建模相关的技术 （1）在软件系统静态模型的基础上建立出相应的动态模型 在建立出软件系统的静态模型基础上，软件系统的分析和设计人员接下来就需要分析和设计软件系统的动态结构，并且建立出相应的动态模型。 因为软件系统的动态模型描述了软件系统随时间变化的行为，这些行为是用从静态模型视图中抽取出的系统瞬间值的变化来描述的。 （2）动态模型的主要内容 软件系统的动态模型主要包括UML顺序图、协作图、状态图、活动图，这些模型图便于分析软件系统的功能行为、印证和修改软件系统的静态结构，满足软件系统用户的功能和非功能性的需求，最终达到满足软件系统的功能目标。 2、交互图----可以对共同工作的对象群体的行为建模 （1）交互图——主要包括协作图和顺序图 交互图主要用于定义软件系统如何实现相关功能的；因为它们能够逐步地显示用例的主要流程，这包括：在流程中需要什么对象、对象相互发送什么消息、什么角色启动流程、消息按什么时序发送等方面的信息。 （2）交互图中的“交互”含义 它描述了一个交互，由一组对象和它们之间的关系所组成，这包括在对象间传递的信息。 （3）顺序图和协作图的不同点 1）时序图（顺序图） 它强调消息时间顺序的交互图，描述类系统中类和类之间的交互，将交互建模成消息交换。下图为某个银行项目中用户取钱的顺序图示例：
2）协作图 和时序图一样，协作图也显示用例中特定情形的流程。但时序图按时间排序，而协作图则着重于对象之间的关系。 （4）顺序图和协作图示例 1）下面为一个软件系统中的用户注册的顺序图 2）而下面则为与前面的用户注册的顺序图相对应的协作图。