| 编辑推荐: |
本文总结了概念类图，如何创建概念类图进行迭代建模的几个方面，希望对您有所帮助
本文来自Agile Modeling ，由火龙果软件琪琪编辑推荐 |
|
UML2 类图是面向对象的分析和设计的主体。UML 2类图显示了系统的类，它们之间的相互关系（包括继承，聚合和关联）以及类的操作和属性。类图可用于多种目的，包括概念/领域建模和详细设计建模。尽管我更喜欢在白板上创建类图，因为简单的工具更具包容性。
1. 概念类图
图1从大学的概念模型的简单UML类图开始，将类描述为带有三部分的方框，最上面表明类的名称，中间的一个列出类的属性，第三个列出方法。可以说我在做出模型的设计决策通过类中同时包括的属性和方法框，如果我的目标是概念模型，那我就不应该这样做。另一个方法是有两个部分，一个是名称，一个是职责列表，这将接近CRC模型（因此，如果我想采用这种方法，我将使用CRC卡而不是UML类图）我还可以使用仅显示类名称的类框，使我可以只关注类及其之间的关系，然而，如果这是我的目标，那么我将更可能创建一个ORM图，简而言之，我更喜欢遵循AM的Apply
the Right Artifact(s)实践，并使用每种建模技术来获得最佳效果。
图1.概念类图的草图
Enrollment是一个关联类，也称为链接类，用于对具有方法和属性的关联进行建模。关联类通常在分析过程中建模，然后在设计过程中重构为我在图2中显示的内容 （图2 仍然是一个概念图，尽管它具有设计风格）。迄今为止，至少就我所知，尚无主流编程语言支持具有职责的关联的概念。因为您可以通过这种方式直接构建软件，所以我倾向于不使用关联类，而是在分析工作中解决它们。这不是一种纯粹的建模方法，而是实用的，因为团队中的其他成员（包括项目利益相关者）不需要学习关联类的概念和概念。
图2描绘了图1的重做版本，关联类已解决。我本可以在 Seminar类中添加一个名为Waiting List的属性，但是我选择将其建模为关联，因为它实际上代表的是：研讨会对象保留了零个或多个学生对象的等待列表。属性和关联都是UML 2.0中的性能，因此它们基本上被视为同一类事物。我还展示了关联是作为属性和操作的组合实现的-我更喜欢保持模型简单，并假设存在属性和操作以实现关联。此外，无论如何这将是一个详细的设计问题，这在概念模型上是不合适的。
图2.初始概念类图。
在 等待名单 上的关联是单向的，因为现在还没有必要在两个方向上的联合。遵循 AM的做法Create Simple Content ，不要过度建模-您现在不需要双向关联，因此不需要建模。
出于类似的原因，学生和招生之间的录取关联,类也是单向的。对于该关联，学生似乎知道他们所参与的入学记录，记录他们过去参加的研讨会以及他们目前所参与的研讨会。将研究该关联以计算其学生对象的平均分数并提供有关所参加的研讨会的信息。报名和研讨会之间也有一个报名关联，支持学生制作所参加研讨会的列表的功能。该指示的之间的关联教授类和
研讨班类是双向的，因为包括教授知道他们指导什么研讨会和研讨对象知道是谁指导他们。
在进行概念建模时，我的风格是分别使用Attribute Name和Method Name格式命名属性和方法。遵循一致且实际的命名约定有助于使图易于阅读，这是AM 应用模型标准实践的重要好处。另请注意图2 我还没有在很大程度上建模属性和方法的可视化。可视化是设计过程中的重要问题，但是目前，可以忽略不计。还要注意，我还没有为类定义完整的方法签名。这是我通常要设计的另一项任务。
根据此信息，我能够确定所有关联（除了一个关联）的多重性，为此，我用注释进行了标记，因此我想与利益相关者进一步讨论。注意我在笔记中使用问号。我的风格是用这种方式在图表上标记未知信息，以提醒自己我需要研究一下。
在 图2中，我对UML约束进行了建模，在这种情况下， 基于研讨会和学生之间的关联{ordered FIFO}。基本思想是将学生按照先到先得（FIFO）的顺序放在候补名单上。换句话说，将学生按顺序放在候补名单上。UML约束用于在UML图中准确地对复杂和/或重要的信息进行建模。UML约束使用格式“ {constraint description}”格式建模，其中约束描述可以采用任何格式，包括谓词演算。我更喜欢将UML注释与英语注释一起使用，而不是使用正式的约束，因为它们更易于阅读。
2. 如何创建类图
要创建和演化概念上的类图，您需要迭代建模：
类
职责范围
关联
继承关系
关联组成
词汇
要创建和演化设计类图，您需要迭代建模：
类
职责范围
关联
继承关系
关联组成
介面
2.1 类
对象是适用于您的系统的任何人，地点，事物，概念，事件，屏幕或报告。对象既知道事物（它们具有属性）又知道事物（它们具有方法）。类是对象的表示，在许多方面，它只是用于创建对象的模板。类构成了面向对象应用程序的主要构建块。尽管成千上万的学生上大学，但您只能模拟一个班级，称为Student，它将代表整个学生集合。
2.2 职责范围
通常将类建模为具有三个部分的矩形：顶部为类的名称，中间为类的属性，底部为类的方法。可以使用与进行 CRC建模时相同的方式来识别模型的初始类 ，以及最初的职责（其属性和方法）。属性是关于对象存储的信息（或者至少是关于对象临时维护的信息），而方法是对象或类要做的事情。例如，学生有学生编号，姓名，地址和电话号码。这些都是学生属性的例子。学生还注册课程，停课并要求成绩单。这些都是学生所做的事情的示例，这些示例将作为方法实现（编码）。您应该将方法视为函数和过程的面向对象的等效项。
重要的考虑因素是适当的细节。考虑图2 建模的Student类， 它具有一个称为Address的属性。当您停下来想一想时，地址是很复杂的事情。它们具有复杂的数据，例如包含街道和城市信息，并且可能具有特性。图4描述了一种可能更好的建模方法。注意地址类的建模，使其包含的每个数据都包含一个属性，并添加了两种方法：一种用于验证其为有效地址，另一种用于将其输出为标签（可能是信封）。通过引入Address 类，Student类变得更具连贯性。它不再包含与地址相关的逻辑（例如验证）。该 地址类现在可以再使用在其他地方，比如教授的类，降低您的总体开发成本。此外，如果在学期期间需要支持学生使用多个地址，该学生可能会住在其永久邮寄地址以外的其他位置，例如系统可能需要跟踪的宿舍信息。应该有一个单独的类来更容易的实现添加多个地址的这种行为。
图4.学生和地址（概念类图）。
学生类的一个有趣特征是它有资格参加 的职责。下划线指示这是类级别的职责，而不是实例级别的职责（例如，提供参加的研讨会）。职责属于类级别的一个很好的指示，它很有意义，它属于该类，但不适用于该类的单个对象。在这种情况下，此操作将在 参加研讨会系统用例中提到，BR129实现确定注册资格
图2的Seminar类 被重构为图5所示的类 。这样的重构称为类规范化（Ambler 2004），在此过程中，您重构类的行为以增加其内聚性和/或减少类之间的耦合。研讨会是一门课程的提供，例如，“ CSC 148计算机科学概论”课程可能由五次研讨会提供。名称属性和 费用属性移动到课程类和课程编号中 推出。该getFullName（） 方法将课程编号“ CSC 148”和课程名称“ Introduction to Computer Science”连接在一起，以给出课程的全名。这称为getter方法，该操作返回与对象相关的数据值。尽管需要为一个类开发getter方法和相应的setter方法，但通常假定它们已经存在，因此没有进行建模（尤其是在概念性类图上）以免使模型混乱。
图5.标准化的研讨会（概念类图）。
图6描绘了图5中的课程， 将以其getter和setter方法进行建模。getter和setter是不适合概念模型的细节，以我的经验，它们甚至不适合详细的设计图-而是我将设置一个编码准??则，使所有属性都具有getter和setter方法，然后再使用它。有些人确实选择对getter和setter建模，但我认为它们的视觉干扰会在不增加价值的情况下使您的图表混乱。
图6.课程的访问方法（向设计类图倾斜）。
2.3 关联
对象通常与其他对象关联或相关。例如，如图2所示，存在几种关联：学生正在参加研讨会的待办事项列表，教授指导研讨会，研讨会是课程提供的，教授住在地址等等。关联被建模为连接两个类的线，是这两个类的实例（对象）涉及到关系。
在UML类图中对关联进行建模时，您将它们显示为连接两个类的细线， 如图6所示。关联会变得非常复杂；因此，您可以在图表上描述有关它们的一些信息。标签是可选的，尽管强烈建议使用，但通常是描述该关联的一个或两个单词。例如，教授指导研讨会。
图6.关联符号。
仅仅知道教授指导研讨会是不够的。教授们指导多少个研讨会？没有，一个还是几个？此外，关联通常是双箭头：不仅教授指导研讨会，而且研讨会也由教授指导。这就产生了这样的问题：多少位教授可以指导任何给定的研讨会，并且有可能在没有人指导的情况下举办研讨会？这意味着您还需要确定关联的多重性。关联的多样性标记在该行的任一端，表1总结了可以使用的潜在多重性指标。
表1.多重性指标。
关联的另一种选择是指出标签阅读的方向。使用称为方向指示器的实心三角形进行描绘，图5的研讨会 和课程类之间的关联提供了一个示例 。此符号表示应将关联读为“研讨会由课程提供”，而不是“课程由研讨会提供。”如果不清楚应以哪种方式阅读标签，则应使用方向指示符。 。但是，我的建议是，如果您的标签不清楚，则应考虑将其改写。
行尾的箭头指示关联的方向。具有一个箭头的线是单向的，而具有零或两个箭头的线是双向的。正式的来说，应该同时包含双向关联的两个箭头，但是，通常的做法是删除它们（如您所见，我更喜欢删除它们）。
在关联的每一端，也可以指示角色，对象在关联中所处的环境背景。我的风格是仅在信息增加价值时对角色进行建模，例如，知道Student类的角色已在注册中，学生在已注册的关联中不会为该模型添加任何内容。我仅遵循AM练习 Depict Models 指示出角色当关联标签不清晰时，是否存在递归关联或两个类之间是否存在多个关联。
2.4 继承关系
不同类别之间通常存在相似之处。很多时候，两个或多个类将共享相同的属性和/或相同的方法。因为您不想重复编写相同的代码，所以需要一种利用这些相似性的机制。继承就是这种机制。继承模型“是”和“类似”关系，使您可以轻松地重用现有数据和代码。当A从B继承时，我们说A是B和B的子类是A的超类。此外，当A继承B的所有属性和方法时，我们说“纯继承” 。用于继承的UML建模表示法是一条线，该线带有从子类指向超类的闭合箭头。
图2的学生类和教授类 之间存在许多相似之处 。它们不仅具有相似的属性，而且具有相似的方法。为了利用这些相似之处，我创建了一个名为Person的新类， 并让Student和Professor都继承了该类， 如图7所示。该结构称为“ Person” 继承层次结构，因为Person是其根基。该Person是一个抽象类：对象没有直接创建的，它抓住了学生和教授之间的相似性。与具体类相反，抽象类的名称以斜体建模，而具体类则是实例化对象的类，其名称以普通文本表示。这两个类都具有名称，电子邮件地址和电话号码，因此这些属性已移至 Person。在购买停车证这两个类之间的方法也很常见，这是我们在绘制 图2之后发现的，因此也移到了父类中。通过将继承关系引入模型，我减少了要执行的工作量。这些职责不是在两次执行这些职责的情况下而是在Person类中执行一次，并由Student 和Professor重用。
图7.继承层次结构。
2.5 组成关联
有时，一个对象由其他对象组成。例如，一架飞机由机身，机翼，发动机，起落架，襟翼等组成。图8给出了一个使用组合的示例，该模型模拟了一个建筑物由一个或多个房间组成的事实，然后，一个房间可能由几个子房间组成（您可以具有递归组合）。在UML 2中，集合将显示为空心菱形。
图8.建模组成。
我坚定地相信句子规则的“一部分”-如果说某物是别的东西的一部分是有意义的，那么很有可能构成是有意义的。例如，说一个房间是建筑物的一部分是很有意义的，说一个地址是一个人的一部分是没有意义的。组成有意义的另一个很好的迹象是，零件的生命周期是由整体管理的，例如，一架飞机管理着引擎的活动。在决定是否使用组成关联时，克雷格·拉曼（Craig Larman（2002））说的最好：如果有疑问，请不要理会。不幸的是，当现实在编码级别的关联和组成之间几乎没有差异时，许多建模者会为何时使用合成感到烦恼。
2.6 词汇
在 敏捷数据库技术（Ambler 2004）中，我讨论了在建模 XML数据结构时词汇的重要性。 。词汇表定义实体类型的语义及其职责，实体类型之间的分类关系以及实体类型之间的本体关系。语义仅仅是含义的花哨词-当我们定义某种事物的语义时，我们就是在定义它的含义。分类法是将实体类型分类为层次结构，并为个人提供了一个示例图9。本体论超越了分类学。分类法解决分类层次结构时，本体将表示和传达有关主题以及该主题中包含的实体的一组关系和属性的知识。
图9.大学内部人员的分类。
概念模型的语义最好在 词汇表中找到。图9有几个有趣的方面 ：
它对类采用“单节”方法，而不是前面的图中所见的三节方法，因为我们正在研究实体类型之间的关系，而不是它们的职责。
它使用UML 2.0的泛化集合概念，基本上只是一个继承箭头，带有一个代表集合名称的标签。在UML 1.x中，此标签称为鉴别符。有三个泛化集人： 国籍，角色和性别。
这些概括集重叠-可以通过这些角色中的每一个对一个人进行分类（例如，某人可以是外国留学生）。这称为多重分类。
您可以指示“子概括”集，例如 “ 角色概括”集中的“ 学生 ” 。
一些通用集与其他通用集互斥，在实体类型可能只在一个集中的示例中未显示。这称为单一分类，并且将使用两个（或多个）鉴别符之间的XOR（异或）约束来建模。
|
