内容


在 Rational Software Architect V7.5 版本中分析模型的需求追踪性

从分析建模过程中的用例追踪需求

Comments

通常来说,软件结构面临着实现用例,以及创建系统逻辑性结构方面的挑战。IBM Rational Unified Process-based (基于 RUP)分析模型不但可以帮助您理解需求,还能帮助您设计总体的方案。本文包括了以下的话题:

  • 基于 RUP 的分析过程,通过 IBM® Rational® Software Architect 7.5 来建模系统的静态或者动态行为(分别通过序列图及分析类和它们之间的关系来实现)。
  • 分析模型的重要性,以及它们怎样适应模型驱动的结构。
  • 怎样使用 Rational Software Architect 7.5 来追踪从用例模型到分析模型的技术。

模型驱动的结构

模型驱动的结构(MDA)使用适当的特定域语言的独立平台模型,来定义系统功能。在这种方法之中,模型驱动程序之中构件的设计与构筑。

然后,在与 Java™ Enterprise Edition (JEE)或者 Microsoft®.NET 之类相关的平台定义模型条件下,独立平台模型会转化为可以在电脑上运行的一个或者多个特定平台的模型。特定平台的模型可以使用不同的特定域语言(DSLs)或者通用目的语言,例如 Java,C#,PHP 或者 Python。

MDA 中模型的分类

模型可以分类为以下的几类(同样见于以下的图 1),从抽象的(1) 到特定的(3):

  1. 电脑独立模型(CIM)
  2. 平台独立模型(PIM)
  3. 特定平台模型(PSM)
图 1. MDA 中的模型
从抽象到具体的演示
从抽象到具体的演示

电脑独立模型(CIM)
CIM 代表了最高抽象层次之上的系统,也叫做 或者 业务 模型。CIM 的目标在于,在业务的范围内完整地为问题建模,而不用去关注具体方案或者方案实施的方法。它有助于与软件开发团队一起共享业务需求。

平台独立模型(PIM)
软件结构师与设计师使用 PIM 来描述高层次的软件方案,独立于方案的部署平台之外。方案的最高层次可以转化为多种特定平台的模型。

特定平台模型(PSM)
PSM 包含了 PIM 中找到的具体内容,与代表方案在平台上所实施方式的联系。正如其名字所暗含的一样,它包括了关于模型中特定平台的具体内容。

关于分析模型

分析模式描述了您正在建模的系统或者程序的结构。它由 图与 序列 图组成,它描述了您在用例模型中识别的功能性需求的逻辑性实施或者实现。

分析模型识别了系统中的主类,并包含了一系列的用例实现,它包含了系统所构建的方式。类图 使用构造型以建模系统的功能性部分,描述了系统的静态结构。序列图 通过描述执行事件时,来描述用例中事件流程,来实现用例。这些用例实现,对特定用例中的部分系统怎样交流进行了建模。

您可以将分析模型,当作设计模型的基础,因为它描述了系统的逻辑性结构,但是没有描述它实施的方式。

分析模型通常是平台独立的(一个 PIM),这意味着这些模型是与技术无关的。您可以使用 任意技术(Java™ Enterprise Edition [JEE],Microsoft® .NET 等等)的分析模型。

分析图中类的种类

分析模型中有三种类型的泪(同样见于图 2 ):

  • 限制类
  • 控制类
  • 实体类
图 2. 分析模型类
 3 类的简单演示

限制类
系统与系统外围之间的中介。角色会通过联系类来进行交流(例如,JavaServer Pages,或者 JSPs,.NET 程序之中的 JEE 或者 ASP )。

控制类
联系类以及实体类或者其他构件之间的协调。它包含了逻辑以调用适当的构件,从而完成路径。

实体类
它代表了系统中的业务实体。这些类通常包含了一些永久性的特征(例如:Driver Ticket System 之中的 Driver,Ticket 等等)。

怎样创建一个分析模型

分析模型由描述 Driver Ticket System 静态结构的 模型,与作为序列图的用例内容 用例实现 组成。

通过按照下面的步骤进行操作,您可以为用例模型中所描述的 Driver Ticket System,创建一个分析模型(查看资源部分之中的附属项目交换文件 RSA-ReqPro-PIF.zip ):

  1. 下载 部分下载 RSA-ReqPro-PIF.zip 文件到暂时性的文件夹之中。
  2. 选择打开 Rational Software Architect 工作区,并选择 File > Import,然后选择 Project InterchangeNext,来将 .zip 文件作为一个 Project Interchange 选项导入,如图 3 所示。
图 3. 导入 Project Interchange 文件
Import 界面,Select 视图
Import 界面,Select 视图
  1. 选择您的 .zip 文件,然后点击 Finish,如图 4 所示。
图 4. 选择文件
Import Projects 界面
Import Projects 界面
  1. 现在打开您的 My Article 建模项目,并评审 Driver Ticket System 的用例模型。在该包中有五种用例:
图 5. 评审用例
用例模型的 Project Explorer 视图
用例模型的 Project Explorer 视图
  1. 现在是时候创建分析模型。选择 File > New > Model 来创建一个分析模型。保持所有默认的值不变,然后选择 Next。
图 6. 创建一个新的分析模型
Create Model 界面
Create Model 界面
  1. 现在,从 Categories 中选择 Analysis and Design,并从 Templates 中选择 RUP Analysis Package,选择 My Article Modeling 作为目的文件夹,然后点击 Finish (见于图 7)。
图 7. 选择一个模板
Create Model 视图
Create Model 视图

现在您可以在 Project Explorer 视图中查看 RUP Analysis 模型(选择 My Article Modeling >Models > RUP Analysis Model),如图 8 所示。

图 8. RUP 分析模型
Project Explorer 视图
Project Explorer 视图
  1. 接下来,目标就是创建系统的域模型。在这个过程中,应该识别所有的类。为了识别这些类,首先您必须分析用例文献(查看用例模型),并列出遇到的所有项目。该列表为组成域图表的视图、控件与限制元素,提供了一个基础。接下来的列表包含了 Driver Payment System 用例文献之中所有的项目:
    • Driver
    • Ticket
    • Catalog
    • Payment

在仔细分析用例模型或者文件之后,接下来的类会作为 Boundary、Control 以及 Entity 建模,如下面的表格所示。

限制控制条目
票务入口
支付入口
票务处理控件
支付处理控件
司机
票务
类别
支付

现在是时候完成分析模型构建块了。

首先,强调 ${functional.area} 模板,点击 Ctrl+C 来复制它,然后在分析构建块中点击 Ctrl+V 来将其粘贴(见于图 9)。

图 9. 复制并粘贴模板
建模 Library Analysis Building Blocks 文件夹
建模 Library Analysis Building Blocks 文件夹
  1. Copy_1_${functional.area} 重命名为 Driver Payment System (见于图 10)。
图 10. 重命名功能性区域文件夹
显示新文件夹名
显示新文件夹名
  1. 复制,粘贴,并重命名(Boundary,Control,Entity (根据前面的表格)为 ${functional.area} Analysis Elements 以及 Use Case Template,${use.case} 重命名为 Driver Payment System 包,如图 11 所示。
图 11. 类的放置
类的放置
类的放置
  1. 现在复制 ${use.case} 模板,将其粘贴到相同的文件夹之中,并使用适当的用例来将其重命名(见于图 12 )。
图 12. 实现的位置
实现的位置
实现的位置
  1. 现在是时候将分析类和用例实现拖拉到默认的图表之中。分别见于图 13 和图 14。
    • 票务支付处理。查看图 16 中 Ticket Payment 用例之下的 Ticket Payment Processing。
图 13. Project Explorer 之中的分析类图
Driver Payment System 分析元素
Driver Payment System 分析元素

图 13 的大图

图 14. 用例实现概述
Driver Payment System 用例实现
Driver Payment System 用例实现

图 14 的大图

  1. 为用例规格中所描述的所有序列创建用例实现。(对于这里的范例,您可以在第 13 步中查看它)。使用所有的分析类,来创建一个用例实现或者序列图。它就是每一个序列图的通用序列:
    Actor > Boundary Class > Control Class > Entity Class > Data Source
  2. 为了给主用例 Ticket Payment 创建一个用例实现,您需要实现以下的序列:
    • 获取票务信息。 它包含了获取司机的信息,问题的本质,以及票务的收费情况(财务罚款)。查看图 15 以得到 Ticket Payment 用例的基本 Retrieve Ticket Info Flow。
    • 票务支付处理。 查看图 16。Use Case Ticket Payment 之下的票务支付处理。
图 15. Retrieve Ticket Information 处理流程
流程图
流程图

图 15 的大图

图 16. Ticket Payment 处理流程
流程图
流程图

图 16 的大图

功能中以下的用例是附属的或者可选的。

  • 网上票务支付 。查看图 17。对主用例重复使用序列,Ticket Payment。
图 17. 网上票务支付子用例
流程图
流程图

图 17 的大图

  • 电话票务支付 。查看图 18。从主用例中重复使用序列,Ticket Payment。
图 18. 电话票务支付子用例
流程图
流程图

图 18 的大图

  • 获取司机信息。该附属用例是通过 Ticket Entity 用例来访问的(见于图 19)。
图 19. 获取司机信息子用例
流程图
流程图

图 19 的大图

  • 访问点类别。这是一个可选择的用例,可以由司机之类的角色访问 (见于图 20)。
图 20. 访问点类别可选性用例
访问点类别
访问点类别

图 20 的大图

怎样制作视角图

现在,在完成构建模块之后,分析元素(类),以及用例实现,Driver Ticket Payment System,现在是时候完成视角概述图了。

  1. 展开包 «视角» Overviews 并完成图表。对于 Driver Ticket System UIKey ControllersKey Abstraction 以及 Domain 模式, 点击相关的图表并从 Analysis Elements 包中拖拉重要的分析类,如下面所示:
    • 图 21 显示了 PaymentEntry,PointCatalog 以及 TicketEntry 作为限制类。
    • 图 22 显示了 CatalogPointProcessing,TicketProcessing 以及 PaymentProcessing 作为控制类。
    • 图 23 显示了 Payment,Catalog,Driver,Ticket 作为实体类。
    • 图 24 显示了 Driver Ticket System 的关键抽象情况。
图 21. Driver Ticket System UI 视图
3 个分析类模板作为  Boundary
3 个分析类模板作为 Boundary

图 21 的大图

图 22. Driver Ticket System Key Controllers 视图
3 个分析类视图作为 Control
3 个分析类视图作为 Control

图 22 的大图

图 23. Driver Ticket System Domain Model 视图
4 个分析类模板作为 Entity
4 个分析类模板作为 Entity

图 23 的大图

图 24. Driver Ticket System Key Abstractions 视图
 9 个重要分析类的图
9 个重要分析类的图

图 24 的大图

  1. 现在您要创建一个最终的 Driver Ticket System Analysis 概述图:点击 Driver Ticket System Analysis Overview 图表,并从分析构建模块及 «视角» Overviews 包中,拖拉功能性区域包,Driver Ticket Payment System(见于图 25)。
图 25. Driver Ticket System Analysis Model Overview 视图
用例之下的视角 Overviews
用例之下的视角 Overviews

图 25 的大图

怎样让需求变得可以追踪

在分析模型之中创建有两个主要的产物:分析类与用例实现。按照下述步骤来创建从作为用例的需求到实现,从实现到分析类的追踪性:

  1. 从一个用例到一个用例实现的追踪性:从用例模型中强调主要的 Ticket Payment 用例并从下拉菜单中右击并选择 Query > Traceability > Specification
  2. 将结果保存在 .dnx 文件之中(见于图 26)。
图 26. 用例中的追踪性
Traceability.dnx 项视图
Traceability.dnx 项视图

图 26 的大图

您还可以 用例实现中创建追踪性:

  1. 强调 Ticket Payment 用例实现,并右击以选择 Query > Traceability > Implementations。您可以追踪所有的工件,如图 27 所示。
图 27. 用例实现的追踪性
项目视图的实现
项目视图的实现

图 27 的大图

总结

在为文章中提到的问题完成分析模型之后,您可能已经知道怎样实现用例,以及创建系统的一个逻辑性结构。分析模型可能不能让您全面了解系统,但是可以帮助您追踪相关的需求。作为一个平台独立的模型,分析模型为特定平台的所有企业设计提供基本的构建模块。

您可以在 下载 部分之中找到 AnalysisModel.zip 以及 Project Interchange File (PIF)文件。


下载资源


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=577376
ArticleTitle=在 Rational Software Architect V7.5 版本中分析模型的需求追踪性
publish-date=09032010