在智能控件化虚拟仪器系统的开发中，通过使用软件体系结构作为指导，使开发顺序变得清晰。首先，实现那些同智能虚拟控件的执行和交互相关的部分，建立一个稳定的系统软件体系结构。然后，基于开发队伍的层次和类型，依次实现增量部分。这样，在系统开发早期就可以产生一个可运行的系统，以此识别在开发过程中可能遇到的种种问题，并以稳定的系统软件体系结构作为集成的基础，使得后来开发出来的各种智能虚拟控件可按照预先规定的接口集成到系统中，实现增量开发。
基于软件体系结构的增量软件开发的基本活动是：
1）首先设计系统的软件体系结构，并明确定义智能虚拟控件的接口和智能虚拟控件之间的交互。
2）实现软件体系结构的集成机制，以及体现子系统行为的智能虚拟控件，从而形成未来系统的基本骨架。
3）根据用户需要，开发符合接口定义的智能虚拟控件并集成到系统中，通过不断地丰富、充实骨架，构造一个最终满意用户需求的系统。
基于上述过程的软件开发具有以下特点：
1）在骨架系统的统一框架下，允许把早期的开发注意力集中在系统最核心或最有可能发生问题的地方，有助于准确地估计开发代价和进度，降低开发风险。
2）系统中的不同智能虚拟控件属于不同的“小领域”，智能控件化虚拟仪器系统包括用户界面部分、特定领域的计算、不同进程的调度算法等，可以把这些不同的智能虚拟控件分配给相应的领域专家；另外，系统的各个智能虚拟控件可以并行开发，有助于提高系统开发效率和质量。
3）因为集成贯穿在整个系统的开发过程之中，使得集成的代价显示化，并被移到了软件开发的前期，从而有效地降低了系统集成的代价和风险。
4）在系统开发过程中，始终保持一个可运行系统的存在，可以及时反映系统的需求变化，评估开发进度和风险。测试和复审可以随着智能虚拟控件或子系统的加入而增量进行，有利于早期发现和解决问题。
良好的软件体系结构为系统的演化提供了稳定的基础，在不影响系统总体结构的前提下，因系统演化而引起的修改被限制在系统的局部，可以通过增加智能虚拟控件或替换有问题的智能虚拟控件而实现。
事实上，上述开发过程是目前工业界普遍采用的开发模型。例如，Microsoft公司采用的“同一步稳定产品开发模型”，将大项目分成若干里程碑式的重要阶段，并在系统开发的早期定义稳定而灵活的软件体系结构，为后续的构件和子系统的开发提供统一的接口，随着构件的不断开发和加入到系统中，在整个开发过程中始终维持一个可发布的系统版本，不仅可以准确把握项目进展情况，增强开发人员的信心和成就感，而且可以随时根据市场情况及时作出调整。
在可复用的智能虚拟控件库的支持下，智能控件化虚拟仪器系统的开发分为若干个不同的活动：需求获取、需求规约、软件体系结构设计、智能虚拟控件获取和系统集成，如图8-18所示。
图8-18 DR-HMB模式下系统开发
1.智能虚拟控件和对象
结构化软件开发采取功能分解的方法，将一个系统分解为不同的功能模块，模块之间通过控制（模块调用）和数据进行通信，系统的基本组成单元是功能模块。面向对象方法以“对象”为核心进行系统建模，对象是数据和操作的封装体，消息是对象之间进行通信的唯一手段，系统的基本组成单元是对象。在最早的面向对象语言Smalltalk中，对象对外只提供操作，属性是通过操作访问的；CORBA、DCOM和EJB中的构件通过接口提供了操作的集合，属性的访问和修改要通过get和set操作。从以上分析看出，这里的构件形态是通过一组接口向外提供服务的实体。一个接口是一组操作的封装，一个构件可以对外提供多个接口，使构件对系统呈现为不同的角色。数据用于存储构件的状态，以完成构件对外承诺的责任，对构件外部而言数据属于内部细节。
因此，从上述意义上讲，构件是对象概念的延伸和发展。通常可认为，构件的粒度比对象的粒度更大，它们是独立的功能单元，在实现上可以是一组协作的对象集合，典型的构件如CORBA构件、DCOM构件、JavaBeans构件等。通常存在两类系统，①对象系统：对象具有小粒度、大数量的特点，如一般的面向对象系统；②构件系统：构件具有大粒度、小数量的特点，典型的如客户-服务器模式、基于消息总线的CORBA构件组成的系统等。
根据以上分析，在HMB模式的智能控件化虚拟仪器系统的软件开发中，可以借用传统面向对象开发方法中许多成熟的思想，类似地可以建立use-case模型、智能虚拟控件关系模型、智能虚拟控件交互模型、智能虚拟控件状态模型等，区别在于这里的智能虚拟控件通过接口定义了向外提供的服务和要求环境的服务。
2.需求获取
需求获取的目标是：发现真正的需求，并以易于理解的方式表现给管理者、用户和开发人员等。use cases目前被认为是一种较好地获取软件系统需求的手段，特别是在基于构件的系统开发中。通常，一个系统有许多不同类型的用户，每种类型的用户作为系统的一类活动者，通过和use cases的交互使用系统。一个use-case表示了系统向活动者提供一些有价值的结果而执行的动作序列。所有活动者、use cases和它们之间的关联构成了系统的use-case模型，反映了用户同系统的交互，刻画了系统的功能和行为。
use cases提供了一种系统和直观地获取功能需求的方式，将分析人员的注意力集中于捕获系统为每个用户（即活动者）所提供的服务上。在需求获取方面，use cases强调系统为每类用户提供的功能，从而引导分析人员根据用户的实际需要发现系统的功能。不为任何用户所需的功能是系统不应包含的，而任何用户的每种需求又恰恰是系统中必须包含的，这样就是用户的真正需求和分析人员获取的需求之间建立了一一对应的关系。
use cases比较好地刻画了系统的功能性需求。系统的非功能性需求，通常分为两种：特定于某个use case的，往往可以在use cases的描述中说明；不是特定于某个use case的，而是有关多个use cases或系统全局的，在其他地方予以说明，例如，系统效率、持久性、透明智能虚拟控件分布、系统安全、错误诊断和恢复、事务处理等。这些非功能性需求一般可在软件体系结构设计阶段考虑，通常涉及操作系统、数据库、通信机制、中间件等。(www.xing528.com)
3.需求规约
需求规约阶段的主要任务是以准确、无二义的方式刻画用户需求，使开发人员能更准确地理解在需求获取阶段得到的use-case模型，把use cases细化为智能虚拟控件和智能虚拟控件之间的交互。这个阶段以use-case模型作为输入，产生的结果主要包括智能虚拟控件关系模型、智能虚拟控件交互模型和智能虚拟控件状态模型。
标识系统的智能虚拟控件是所有这些模型的基础。通过use cases，识别参与实现use case的智能虚拟控件，并把use cases中定义的责任分配给不同智能虚拟控件。以这种方式，可以确定系统真正需要的、并实现use cases的一组智能虚拟控件。对这组被确定的智能虚拟控件，可以直接复用智能虚拟控件库中现有的智能虚拟控件，或根据实际情况对智能虚拟控件和use cases进行适应性修改。
在智能虚拟控件关系模型中，智能虚拟控件之间的关系包括统一描述语言（Unified Modeling Language，UML）中的关联和依赖两种，聚集和包含是特殊的关联关系。值得注意的是，这里并没入引入一般关系，在面向对象中是通过继承机制体现的，可以很好地支持源代码级的复用，但也存在着一定的局限性，其中最突出的是被称为“脆弱的基类问题”。继承机制在支持复用时，子类可以直接使用父类提供的属性和服务，并根据需要做适应性修改，一旦继承树中的某个非叶节点的接口发生变化时，这种影响就会波及以该节点为根的整个子树，有时这种波及并不是所希望的；继承机制还会带来复用的效率问题，复用一个子类会引入该子类的所有父类，如果整个继承树很大，会消耗很长的时间，这也是面向对象在一些对性能要求很高的领域难以广泛使用的原因之一。在智能虚拟控件关系模型中，通过使用聚集和包含来实现智能虚拟控件之间的复用。智能虚拟控件交互图可以分为协作图和顺序图两种。每个use case可以被智能虚拟控件交互图实现，它们之间具有无缝的追踪关系，复杂智能虚拟控件在其活动周期内可以处于多种不同的状态，可以使用状态刻画其状态变迁。
4.软件体系结构设计
软件体系结构是从问题空间向软件解空间过渡的第一个活动，以需求规约为基础，在考虑系统实现环境（如操作系统、数据库、通信机制、中间件等）和应遵循的标准等因素的情况下，通过复用特定领域的软件体系结构，形成该系统的软件体系结构。软件体系结构是系统实现的蓝图，在后续开发活动中的作用包括以下两个方面：规定了构件接口和规约，有助于构件获取，例如，定制或发现相关的构件；为系统集成提供了框架，有助于符合规定接口的构件集成。
DR-HMB模式支持系统的自顶向下设计，首先从高层描述组成系统的智能虚拟控件和智能虚拟控件之间的交互关系，然后把这些智能虚拟控件逐层分解下去，上层智能虚拟控件的接口是由下层智能虚拟控件的对应接口实现的，直至最底层的叶结点，其粒度以便于实现为止。
在辅助工具的支持下，可以对系统的静态性质进行分析，并可动态模拟运行。动态模型运行的结果反映了智能虚拟控件之间的实际交互情况，一方面可以同系统的use-case模型和智能虚拟控件交互模型进行比对，验证这样的软件体系结构设计是否符合用户同系统的实际交互情况，即满足用户的需求；另一方面还可以看作是一个原型系统，供用户评价，这样就可以在软件系统结构的构造过程中及时得到反馈。通过模拟运行和用户反馈，及早得到该系统的一个稳定的软件体系结构。
5.智能虚拟控件获取
需求规约结果包括智能虚拟控件关系模型、智能虚拟控件交互模型和状态模型，软件体系结构定义了智能虚拟控件的接口和相应的规约，为智能虚拟控件的获取提供了依据。
在DR-HMB模式系统开发中，智能虚拟控件的获取包括以下几种不同的方式：
1）直接从智能虚拟控件库中获得符合要求的智能虚拟控件。
2）对智能虚拟控件库中的智能虚拟控件进行适应性修改。
3）开发新的符合要求的智能虚拟控件。
在进行以上决策时，必须考虑不同方式获取智能虚拟控件的一次性成本和以后的维护成本。
6.系统集成
在DR-HMB模式的系统开发中，软件体系结构为系统集成提供了指导和框架，这就意味着在系统开发的早期显式地考虑了集成问题，从而降低了集成的风险。不仅如此，在增量的系统开发中，根据需求的优先顺序，基于稳定的软件体系结构，智能虚拟控件一边开发一边集成到系统中，集成贯穿系统的整个过程。
智能虚拟控件之间通过消息总线进行通信，可以比较方便地实现系统集成，系统集成组装流程图如图8-19所示。
图8-19 系统集成组装流程图
在图8-19中，文本编辑和可视化编辑器用于建立系统的软件体系结构描述，描述包括了智能虚拟控件的规约，据此智能虚拟控件库管理系统可以对符合规约的智能虚拟控件进行查询和获取，拼搭场根据描述和获取的智能虚拟控件，完成系统的集成，形成智能控件化虚拟仪器。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
