养成良好的绘制 UML 序列图的习惯

下载本文示例代码
本文转自IBM developerWorks 中国网站　　请尝试本文所介绍的技巧来创建有效的 UML 序列图。本文改编自 The Object Primer 2nd Edition 的第 6 章。 　　有一些方法可以帮助您提高 UML 序列图的质量和效力。它们包括： 　　　和主题问题专家一起验证决策 　　　使解决方案尽量简单 　　　为绘制消息和返回值选择一种一致而有效的风格 　　　将序列图分层 　　　遵循一致的逻辑风格 　　　牢记序列图是动态的 　　验证决策　　在开发图 1 序列图的过程中，我做了一些对其它模型可能有潜在影响的决策。例如，在对第 10 步建模时，假设（大致上是个设计决策）费用显示屏幕同时也处理学生对费用是否可接受所进行的验证。该决策应该由用户界面原型反映出来，并由主题问题专家 (SME) 进行验证。您应该和 SME（特别是那些对于如何开发类似模型有着深刻见解的富有经验的人）一起执行序列图的绘制工作。　　保持简单　　在对第 2 和第 3 步建模时，我忽然意识到学生可能应该使用口令进入系统。在向 SME 提出了这个概念后发觉我错了：姓名和学号组合对于我们的目的来说已经足够唯一，并且学校也不希望增加复杂的口令管理。这是个很有意思的决策，因为这是学校的一个运作策略，所以可以作为一条商业规则记载到增补规范中。通过与 SME 一起检验这个想法，而不是假定我比他们知道得更多，我避免了“镀金”的机会，因而减少了我们小组开发这一系统所需的工作。　　绘制消息和返回值　　我更喜欢从左至右地绘制消息，从右至左地绘制返回值，尽管这样对于复杂的对象／类来说不总是非常合适。我将消息上的标签和返回值对齐到离箭头最近的位置。我不喜欢在序列图上标出返回值，为的是使图尽可能地简化。不过，始终标出返回值也同样有效，特别是在序列图用于设计而不是分析目的时。（我希望我的分析图尽量简单，而设计图尽量全面。）在分析期间，我的目标是理解逻辑和确保逻辑的正确性。而在设计期间，则要赋予消息精确的细节，如图 1 中的注释提醒我对 "qualifications()" 消息执行的任务。　　将序列图分层　　我喜欢将序列图从左至右地分层。先标出参与者，然后是控制器类，然后是用户界面类，最后是商业类。在设计期间，可能需要添加系统类和持久类，我通常将它们放在序列图的最右侧。以这种方式将序列图分层往往使它们更易于阅读，并且更容易找出分层逻辑问题，例如用户界面类直接访问持久类（在今后的建模技巧中将对此做更多介绍）。　　遵循一致的逻辑风格　　请注意，在图 1 序列图所示的过程中，逻辑风格做了部分更改。一开始，特别是在登录时，用户界面处理一些基本逻辑 -- 而在选择研习班，以及稍后的验证时，则是控制器类进行处理。这实际上是个设计问题。我不会在这个问题上纠缠太久，但和往常一样，我建议选择一种适合于您的建模风格，然后始终如一地贯彻在所有序列图中。　　牢记序列图是动态的　　您可能听说过诸如动态建模和静态建模这样的术语，其他一些熟悉面向对象建模技术的开发人员常常会提到它们。您甚至可能听到过有关每种风格的优点的争论。　　动态建模技术主要集中在标识系统中的行为，包括序列图的绘制和活动图的绘制（请参阅“如何绘制 UML 活动图”）以及 UML 协作图的绘制。而静态建模则集中在系统的静态方面，包括类、它们的属性，以及类之间的关联。类模型和持久／数据模型一样，都是静态建模的主要产物。　　因此实际上没有什么好争论的 -- 要想恰如其分地说明面向对象系统，同时需要动态和静态建模技术。 本文转自IBM developerWorks 中国网站　　请尝试本文所介绍的技巧来创建有效的 UML 序列图。本文改编自 The Object Primer 2nd Edition 的第 6 章。 　　有一些方法可以帮助您提高 UML 序列图的质量和效力。它们包括： 　　　和主题问题专家一起验证决策 　　　使解决方案尽量简单 　　　为绘制消息和返回值选择一种一致而有效的风格 　　　将序列图分层 　　　遵循一致的逻辑风格 　　　牢记序列图是动态的 　　验证决策　　在开发图 1 序列图的过程中，我做了一些对其它模型可能有潜在影响的决策。例如，在对第 10 步建模时，假设（大致上是个设计决策）费用显示屏幕同时也处理学生对费用是否可接受所进行的验证。该决策应该由用户界面原型反映出来，并由主题问题专家 (SME) 进行验证。您应该和 SME（特别是那些对于如何开发类似模型有着深刻见解的富有经验的人）一起执行序列图的绘制工作。　　保持简单　　在对第 2 和第 3 步建模时，我忽然意识到学生可能应该使用口令进入系统。在向 SME 提出了这个概念后发觉我错了：姓名和学号组合对于我们的目的来说已经足够唯一，并且学校也不希望增加复杂的口令管理。这是个很有意思的决策，因为这是学校的一个运作策略，所以可以作为一条商业规则记载到增补规范中。通过与 SME 一起检验这个想法，而不是假定我比他们知道得更多，我避免了“镀金”的机会，因而减少了我们小组开发这一系统所需的工作。　　绘制消息和返回值　　我更喜欢从左至右地绘制消息，从右至左地绘制返回值，尽管这样对于复杂的对象／类来说不总是非常合适。我将消息上的标签和返回值对齐到离箭头最近的位置。我不喜欢在序列图上标出返回值，为的是使图尽可能地简化。不过，始终标出返回值也同样有效，特别是在序列图用于设计而不是分析目的时。（我希望我的分析图尽量简单，而设计图尽量全面。）在分析期间，我的目标是理解逻辑和确保逻辑的正确性。而在设计期间，则要赋予消息精确的细节，如图 1 中的注释提醒我对 "qualifications()" 消息执行的任务。　　将序列图分层　　我喜欢将序列图从左至右地分层。先标出参与者，然后是控制器类，然后是用户界面类，最后是商业类。在设计期间，可能需要添加系统类和持久类，我通常将它们放在序列图的最右侧。以这种方式将序列图分层往往使它们更易于阅读，并且更容易找出分层逻辑问题，例如用户界面类直接访问持久类（在今后的建模技巧中将对此做更多介绍）。　　遵循一致的逻辑风格　　请注意，在图 1 序列图所示的过程中，逻辑风格做了部分更改。一开始，特别是在登录时，用户界面处理一些基本逻辑 -- 而在选择研习班，以及稍后的验证时，则是控制器类进行处理。这实际上是个设计问题。我不会在这个问题上纠缠太久，但和往常一样，我建议选择一种适合于您的建模风格，然后始终如一地贯彻在所有序列图中。　　牢记序列图是动态的　　您可能听说过诸如动态建模和静态建模这样的术语，其他一些熟悉面向对象建模技术的开发人员常常会提到它们。您甚至可能听到过有关每种风格的优点的争论。　　动态建模技术主要集中在标识系统中的行为，包括序列图的绘制和活动图的绘制（请参阅“如何绘制 UML 活动图”）以及 UML 协作图的绘制。而静态建模则集中在系统的静态方面，包括类、它们的属性，以及类之间的关联。类模型和持久／数据模型一样，都是静态建模的主要产物。　　因此实际上没有什么好争论的 -- 要想恰如其分地说明面向对象系统，同时需要动态和静态建模技术。 下载本文示例代码


养成良好的绘制 UML 序列图的习惯养成良好的绘制 UML 序列图的习惯养成良好的绘制 UML 序列图的习惯养成良好的绘制 UML 序列图的习惯养成良好的绘制 UML 序列图的习惯养成良好的绘制 UML 序列图的习惯养成良好的绘制 UML 序列图的习惯养成良好的绘制 UML 序列图的习惯养成良好的绘制 UML 序列图的习惯养成良好的绘制 UML 序列图的习惯养成良好的绘制 UML 序列图的习惯养成良好的绘制 UML 序列图的习惯养成良好的绘制 UML 序列图的习惯养成良好的绘制 UML 序列图的习惯养成良好的绘制 UML 序列图的习惯