|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（1）关联关系。描述了给定类的单独对象之间语义上的连接。关联提供了不同类之间的对象可以相互作用的连接。其余的关系涉及类元自身的描述，而不是它们的实例。用“ ”表示关联关系。
|
|
|
（2）依赖关系。有两个元素X、Y，如果修改元素X的定义可能会引起对另一个元素Y的定义的修改，则称元素Y依赖于元素X。在UML中，使用带箭头的虚线“ ”表示依赖关系。
|
|
|
|
在类中，依赖由各种原因引起，例如，一个类向另一个类发送消息；一个类是另一个类的数据成员；一个类是另一个类的某个操作参数。如果一个类的接口改变，则它发出的任何消息都可能不再合法。
|
|
|
（3）泛化关系。泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说子类是从父类继承的，而父类则是子类的泛化。在UML中，使用带空心箭头的实线“ ”表示泛化关系，箭头指向父类。
|
|
|
（4）聚合关系。聚合是一种特殊形式的关联，它是传递和反对称的。聚合表示类之间的关系是整体与部分的关系。例如，一辆轿车包含四个车轮、一个方向盘、一个发动机和一个底盘，这就是聚合的一个例子。在UML中，使用一个带空心菱形的实线“ ”表示聚合关系，空心菱形指向的是代表“整体”的类。
|
|
|
（5）组合关系。如果聚合关系中的表示“部分”的类的存在与否，与表示“整体”的类有着紧密的关系，例如“公司”与“部门”之间的关系，那么就应该使用“组合”关系来表示这种关系。在UML中，使用带有实心菱形的实线“ ”表示组合关系。
|
|
|
（6）实现关系。将说明和实现联系起来。接口是对行为而非实现的说明，而类中则包含了实现的结构。一个或多个类可以实现一个接口，而每个类分别实现接口中的操作。实现关系用“ ”表示。
|
|
|
（7）流关系。将一个对象的两个版本以连续的方式连接起来。它表示一个对象的值、状态和位置的转换。流关系可以将类元角色在一次相互作用中连接起来。流的种类包括变成（同一个对象的不同版本）和复制（从现有对象创造出一个新的对象）两种。用“ ”表示。
|
|
|
|
：对于聚合关系和组合关系，各种文献的说法有些区别。在这些文献中，首先定义聚集关系（整体与部分的关系），然后再把聚集关系分为两种，分别是组合聚集（相当于上述的“组合关系”）和共享聚集（相当于上述的“聚合关系”）。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Erich Gamma在他的博士论文中总结了一系列的设计模式，做出了开创性的工作。他用一种类似分类目录的形式将设计模式记载下来。我们称这些设计模式为设计模式目录。根据模式的目标（所做的事情），可以将它们分成创建性模式（creational）、结构性模式（structural）和行为性模式（behavioral）。创建性模式处理的是对象的创建过程，结构性模式处理的是对象／类的组合，行为性模式处理类和对象间的交互方式和任务分布。根据它们主要的应用对象，又可以分为主要应用于类的和主要应用于对象的。
|
|
|
|
下表是Erich Gamma等总结的23种设计模式，这些设计模式通常称为GoF（Gang of Four，四人组）模式。因为这些模式是在“Design Patterns:Elements of Reusable Object-Oriented Software”中正式提出的，而该书的作者是Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides，这几位作者常被称为“四人组”。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（1）类图（class diagram）：描述一组类、接口、协作和它们之间的关系。在面向对象系统的建模中，最常见的图就是类图。类图给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图。
|
|
|
|
（2）对象图（object diagram）：描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。和类图一样，这些图给出了系统的静态设计视图或静态进程视图，但它们是从真实案例或原型案例的角度建立的。
|
|
|
|
（3）构件图（component diagram）：描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。对于由小的部件构建大的系统来说，构件图是很重要的。构件图是类图的变体。
|
|
|
|
（4）组合结构图（composite structure diagram）：描述结构化类（例如构件或类）的内部结构，包括结构化类与系统其余部分的交互点。它显示联合执行包含结构化类的行为的构件配置。组合结构图用于画出结构化类的内部内容。
|
|
|
|
（5）用例图（use case diagram）：描述一组用例、参与者（一种特殊的类）及它们之间的关系。用例图给出系统的静态用例视图。这些图在对系统的行为进行组织和建模时是非常重要的。
|
|
|
|
（6）顺序图（sequence diagram，序列图）：是一种交互图（interaction diagram），交互图展现了一种交互，它由一组对象或角色以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图。
|
|
|
|
（7）通信图（communication diagram）：也是一种交互图，它强调收发消息的对象或角色的结构组织。顺序图和通信图表达了类似的基本概念，但每种图所强调的概念不同，顺序图强调的是时序，通信图则强调消息流经的数据结构。
|
|
|
|
（8）定时图（timing diagram，计时图）：也是一种交互图，它强调消息跨越不同对象或角色的实际时间，而不仅仅只是关心消息的相对顺序。
|
|
|
|
（9）状态图（state diagram）：描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这非常有助于对反应式系统建模。
|
|
|
|
（10）活动图（activity diagram）：将进程或其他计算的结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模特别重要，并强调对象间的控制流程。
|
|
|
|
（11）部署图（deployment diagram）：描述对运行时的处理结点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个结点包含一个或多个部署图。
|
|
|
|
（12）制品图（artifact diagram）：描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品图通常与部署图一起使用。制品也给出了它们实现的类和构件。
|
|
|
|
（13）包图（package diagram）：描述由模型本身分解而成的组织单元，以及它们的依赖关系。
|
|
|
|
（14）交互概览图（interaction overview diagram）：是活动图和顺序图的混合物。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
考虑一个有很多出纳的银行。每一个出纳必须对同一组关系具有同种类型的权限。无论何时指定一个新的出纳，他都必须被单独授予所有这些授权。
|
|
|
|
一个更好的机制是指明所有出纳应该有的授权，并单独标示出哪些数据库用户是出纳。系统可以用这两条信息来确定每一个有出纳身份的人的权限。当一个人被新雇佣为出纳时，必须给他分配一个用户标识符，并且必须将他标示为一个出纳，而不需要重新单独给予出纳权限。
|
|
|
|
角色（role）的概念可用于该机制。在数据库中建立一个角色集，和授予每一个单个用户一样，可将权限授予角色。分配给每个数据库用户一些他（或她）有权扮演的角色（也可能是空的）。
|
|
|
|
事实上，在银行的数据库里，角色的例子可以包括system-administrator、branch-manager、teller和auditor。一个不是很合适的方法是建立一个teller用户号，允许每一个出纳用这个出纳用户号来连接数据库。该机制的问题是它无法鉴别出到底哪个出纳执行了事务，从而导致安全隐患。应用角色的好处是需要每个用户用自己的用户号连接数据库。
|
|
|
|
任何可以授予一个用户的权限都可以授予一个角色。给用户分配角色就跟给用户授权一样。与其他授权一样，一个用户也可以被授予给他人分配角色的权限。这样，可以授予支行经理（branch-manager）分配出纳角色的权限。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
类图（class diagram）展现了一组对象、接口、协作和它们之间的关系。在面向对象系统的建模中所建立的最常见的图就是类图。类图给出系统的静态设计视图。包含主动类的类图给出了系统的静态进程视图。
|
|
|
|
类图中通常包括下述内容：类；接口；协作；依赖、泛化和关联关系，如下图所示。
|
|
|
|
|
|
|
|
类图中也可以包含注解和约束。类图还可以含有包或子系统，二者都用于把模型元素聚集成更大的组块。
|
|
|
|
类图用于对系统的静态设计视图建模。这种视图主要支持系统的功能需求，即系统要提供给最终用户的服务。当对系统的静态设计视图建模时，通常以下述三种方式之一使用类图。
|
|
|
|
|
|
对系统的词汇建模涉及做出这样的决定：哪些抽象是考虑中的系统的一部分，哪些抽象处于系统边界之外。用类图详细描述这些抽象和它们的职责。
|
|
|
|
|
|
协作是一些共同工作的类、接口和其他元素的群体，该群体提供的一些合作行为强于所有这些元素的行为之和。例如当对分布式系统的事务语义建模时，不能仅仅盯着一个单独的类来推断要发生什么，而要有相互协作的一组类来实现这些语义。用类图对这组类以及它们之间的关系进行可视化和详述。
|
|
|
|
|
|
将模式看作为数据库的概念设计的蓝图。在很多领域中，要在关系数据库或面向对象数据库中存储永久信息。可以用类图对这些数据库的模式建模。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
图形是一种矢量图。矢量图是用数学的方式来描述一幅图形，它的基本元素是图元，即图形指令。矢量图形的描述包括形状、色彩和位置等。例如指令Rect（0，0，200，200）表示从坐标（0，0）开始，水平走200个像素点，再垂直走200个像素点，最后形成一个正方形。该指令描述中，所用字符数不到20个字节。矢量图形本身就用数字化形式来表述，其特点是存储量小，且图形的大小变换时不失真。但是，对于一幅复杂的彩色照片，是很难用数学来描述的，因此也难于用矢量图来表示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
收集用户需求是要找出用户需要的重要服务和功能。收集用户需求的机制主要包括与用户群的交流、用户服务和需求归档3个方面。
|
|
|
|
收集用户需求最常用的方式有观察和问卷调查、集中访谈、采访关键人物。在整个设计和实施阶段，应始终保持与关键人员之间的交流，以确保网络工程建设不偏离用户需求。
|
|
|
|
用户服务表用于表示收集和归档的需求信息，也用来指导管理人员和网络用户进行讨论。
|
|
|
|
|
|
|
|
|
|
|
|
|
