18.4 ASEILM 示例

 

此处的示例是在软件工程研究所（Software Engineering丨nstitute, SEI)幵发，用于自 动管理SE丨和其过渡期合作伙伴之间的交互的基于Web的信息系统。创建自动SEI许可人管理（Automated SEI Licensee Management, ASEILM)系统有如下儿个目的：

 

•    支持把SEI许可的资料（如课程和评估套件）分发给经过授权的个人。

 

•    为评估收集管理信息。

 

•    以图形方式提供关于SEI许可资料的费用、出席人数的信息和其他信息,，

 

•    跟踪参加培训课程以及SEI授权的使用费的情况。

 

ASEILM必须支持如下的多个用户类型，每种类型具有执行系统功能的不同的授权„

 

•    课程教师可以输入课程出席者列表、维持联系信息并下载课程资料。

 

•    首席评估员可以安排评估，输入评估信息，并下载评估奄件。

 

•    SEI管理人员可以维护授权教师和首席评估员的列表.以及浏览或编辑山该系统 维护的任何信息。

裉据最初的分析.开发人员能够生成一个系统需求列表，其中的许多需求都直接与所 幵发的系统的质量属性相对应（参见表丨8.1)。

对采用商业组件构建的系统来说，需求协商的正常的意见交换不同于-•般系统的开 发。您可能希望这些组件“免费”提供更多的功能：同时，由于该功能可能并没有准确地 满足组织的需要，因此改变该功能可能是困难的或不可能的，您希望这越少越好。

 

18.1.1 Miva Empressa 组件整体

 

管理人员把用商业组件构建系统看作是开发过程的简化.该开发所需要的经验丰富的 程序员要比标准定制开发少。实际上，相反的-面几乎总是正确的：开发通常是“更’’困 难的，至少采用了新组件集的新开发是这样的。通常需耍丰富的经验来确定用于实现某个 设计的组件；来理解这些组件和其他组件之间的兼容性：来确定需求之间的权衡、特定组 件的使用和总体成本。如果没有这个经验，则必须进行一个耗费时间的搜索和认证过程。

 

在我们的例子中，开发小组己经对Miva Empressa应用服务器有了一定的了解，并且 喜欢使用该服务器作为其最初假定的一部分。Miva Empressa是Microsoft的Internet Information Server(IIS)的扩展，它运行在基于 XML 的 Miva Script 之上， 在 Miva Empressa 之下运行的Miva Script应用在HS内运行，并且可以执行复杂的计算，包括数据库访问。 它们包含在图18.2所示的“定制组件”中。请注意，这是由ASEILM小组从头开发的“惟 一”组件。

 

除了 Miva Empressa应用服务器外，ASE1LM组件整体还使用了几个商业组件：

 

•    作为数据库管理系统的Microsoft Access

 

•    Visual Mining的用于绘制费用、出席人数和其他相关信息的图形的ChartWorks

产品

 

•    作为HTTP服务器的Microsoft 1IS

 

•    作为服务器平台上的操作系统的Windows NT 4.0

 

可以用任意数量的潜在平台和浏览器來表示客户机。最初的组件整体包括Netscape 3.0 浏览器和Windows 98操作系统。Netscape 3.0是个较早的浏览器版本.其能力有限，但 许多首席评估员都使用该浏览器（ASEILM用户的一种 ）。在ASEILM用户群中.Windows 98的使用非常广泛。

 

组件整体的定义是模型过程工作流的•个前置条件。这样,该组件整体就充当了图18.2 中所说明的最初模型解决方案的雉础。在下面的几节中，我们将对模型问题过程进行说明， 所使用的主要假设是Miva Empressa组件整体是一个满意的解决方案。

1.步骤1:确定一个设计问题

 

模型问题过程中的第一步是将一个或多个假定表示为用例或场景.对设计进行测试.

看看组件整体是否是-个可行的解决方案。如下的假定来自表丨8.1给出的系统质量属性

•    假定1。组件整体可以提供对在Access数据库中维护的数据的基于Web的访问 并使用条形图和其他事务图形显示该数据。

 

•    假定2„可以使用HTTPS对Web浏览器和HTTP服务器之间的通信进行加密。

建立假定1主要是为了测试系统的功能以及集成所耍求的组件的能力。建立假定2主 要是为了证明满足所陈述的ASEILM的个安全质量目标的可行性：通过Internet安全传 输数据。

 

在这种情况下，证明这两个假定并没有证明总体组件整体的可行性，但它确实允许通 过评估其额外的所要求的质量属性，使进展朝着证明组件整体可行性的方向发展。同时， 对这些假定的评估还能够提高对组件及其在组件整体中的交互的理解。

 

2.步骤2:定义开始评估的标准

 

评估标准是确定模型解决方案是否支持或反驳最初的假定所必须的。

 

•    标准1。模型解决方案可以使用在Access数据库中存储的数据显示浏览器中的 图表。

 

•    标准2。可以通过HTTPS连接在HTTP服务器和Web浏览器之间传输安全数据。

 

评估标准的成功应该是可验证的，这一点很重要。例如，在标准2的情况下，通常可 以通过观察Web浏览器中锁图标的出现来确定数据传输的安全性。然而，必须使用I正确的测试规程.以确保Web浏览器中所显示的数据实际上起源于数据库.并不是“缓存”在路 线上的某个地方。

 

3.步骤3:确定实现限制

 

限制定义了设计上下文中不可改变的元素。它们确保了设计解决方案对所开发的系统 是有效的。在这个示例中，除了已经确定的限制外，没有实现限制。

 

4.步骤4:产生一个模型解决方案

 

在全面定义了模型问题后，开发小组开始实现模型解决方案——也就是说.支持或反 对假定所必须的最少的应用。在实现期间.确定必须满足以证明组件整体的可行性的额外标准是许可的并且是有益的。

 

在该示例的模型解决方案中，ChartWorks用来对费用、出席人数和其他相关信息绘制 图形。开发人员首先尝试了 •种简单直接的解决方案，它让浏览器给IIS发送•个HTML 语句，以将其转发给ChartWorks。该语句包含一个确定要被绘制图形的数据的査询。然而， 它们发现了两个问题：将图形的标签耦合到该图形的数据中，并维持•个安全的连接。

 

耦合标签和数据-ChartWorks使用图描述语言(Chart Description Language. CDL)

 

来描述图.包括如何从数据库中（在该例子中是Access)提取信息以及如何把信息集成到 数据库中。在该组件整体中.耑耍从Access数据痄中提取图标签和阁数椐，这要求两个不 同的CDL语句。遗憾的是，CDL并不提供任何可以用于对使用不同的语句生成的信息进 行配对的机制。这阻止了其直接查询数据库的使用。相反，Miva用于查询Access数据库， 并创建•个将标签和数据信息组合在•起的文本文件。CDL语句创建用于从该文件中检索数据，而非直接与数据库通信。

 

尽管该方法有效，但它引入了极大的复杂性。例如，有必要跟踪不同用户会话的多个 中间文件，并确保没有混淆这些文件。

 

安全通信——IIS处理的HTML语句指定了由ChartWorks生成的图像的检索。因此， IIS 被迫使用 ChartWorks API。ChartWorks 为 HTTP 提供了 API，但没有为 HTTPS 提供。 这阻止了在ChartWorks和浏览器之间建立安全连接。为了解决这•问题，该小组对删除 IIS和ChartWorks之间的HTTPS连接进行了试验。因为它们位于相同的处理器上，因此安 全性是通过对处理器的访问而非通过通信协议来实施的。遗憾的是.这也没有奏效，因为 在一个Web页而中有安全的和不安全的元素，浏览器或者不允许显示该页面，或者将传输 的不安全部分通知用户。任何-种选择都是不可接受的。

 

为了修复这些问题，该小组创建了一个位于I1S和ChartWorks之间的perl代理服务器。 然后，它们就能够在IIS和代理服务器之间建立一个安全连接，从而使代理服务器能够使用HTTP连接与ChartWorks通信。阁18.3对该解决方案进行了说明。我们对HTML语句 进行了修改.以调用perl代理服务器。

 

5.步骤5:确定结束评估的标准

 

在Miva模型解决方案的实现期间确定了额外的评估标准。尤其是确定了新的质量属 性潘求。在实现期间，我们观察到该解决方案的图形表示元素与后端逻辑紧密纠缠在-起。 这使得图形设计人员很难帮助开发系统的用户接口，因为他们不熟悉通用编程。因此，下 面的评估标准加入了模型问题：

 

•    标准3。必须将表示逻辑的维护与后端业务和数据库逻辑分开，且必须通过定义 良好的接口通信。

 

我们还发现Access数据库并不支持远程连接。尽管从Miva应用服务器通过ODBC接 口与数据库进行通信足可能的，但必须把数据库托管在与IIS服务器相同的平台上。因为 IIS必须位于SEI防火墙的外部以使用户团体能够访问，此数据库必须也在SEI防火墙 的外部。该限制是不可接受的，从而导致增加了第4个标准：

 

•    标准4.。   数据库必须位于防火墙后面的安全位置。

 

6.步耦6:评估模型解决方案

 

在实现了模型解决方案并且确定了额外的评估标准后，设计师就可以根据这些标准对

解决方案进行评估了。

 

通过使用修复机制，可以满足最初的两个标准。然而.亳无疑问，任何•个新标准都 没有满足。因为对任何一个问题都没有明显的修补，我们判断该组件整体是不可行的。

 

18.4.2 Java Servlet 组件整体（使用另外一个组件集成的解决方案）

 

除了基于 Miva Empressa的主要组件整体外，我们确定了一个基于Java servlet的替代 方案。Miva Empressa被作为要研究的主要的组件整体，因为ASE丨LM开发小组拥有组件 专业技术：因此，我们对其投入了大部分项目资源。然而，还需要投入有限的工作对Java servlet组件整体进行评估。该探索是第二次通过模型问题工作流.因此可以保留3步：

 

•    第1步——设计问题没有改变

 

•    第2步——幵始评估标准包括所有4个标准

 

•    第3步——限制没有改变

 

新的评估能够从第4步幵始，这涉及到构建-个模型解决方案，如图18.4所示。

 

该解决方案能够使用在Miva Empressa组件整体中实现的相同进程满足前两个标准。 因为ChartWorks是Java组件整体的一部分,因此开发人员继续使用适配器来修复HTTP/S 不匹配。

 

使用Java servlet允许把系统的表示方面与业务和数据库逻辑分离开。表示逻辑限制为 HTML页面，而业务和数据厍逻辑被移到了在Tomcat应用服务器中执行的servlet和Java bean中，这样就满足了标准3。此外，通过用SQL Server代替Access数据库，开发人员 能够使用远程连接托管防火墙后的数据库，从而满足了标准4。

 

在为新组件整体开发模型解决方案的过程中，将发生如下4件事情：

 

•    最初的标准是不够的，这已经讨论过

 

•    设计部分没有满足最初的标准。尤其是：

 

        ■ 标准2。可以在HTTP服务器和Web浏览器之间通过HTTPS连接传输安全 数据。

 

该标准对确保系统的安全性是不够的，原因已经简要讨论过。

 

•    涉众提出了其他需求

 

•    新的Java组件整体引入了额外的关注点

现在我们对最后3项进行讨论。

 

安全性——除了使数据通过线路安全传输外，身份验证模型需耍重新访问。通过在客 户机上放一个独一无二.的标识符（以cookie的形式）并把它映射到会话上来对用户进行身份验证。开发人员了解到，如果客户机的安全受到了威胁，用户可能会被欺骗，从而危及 到系统的安全性。针对此进行的保护措施是，将所登录机器的IP地址映像到.个独无 一:的标识符上，随后的每次请求都对IP地址进行检查。

 

黑客有时采用跨站脚本的方式进行攻击。在这种情况下，Web形式被保存在黑客的机 器上，并且用某种恶毒的方式进行了修改。然后提交该形式，这可能会导致服务器崩溃. 给客户机显示代码或興他异常信息。ASEILM的解决方案是定义异常以预防此类攻击的 发生。

 

额外的需求-在开发期间，另一个小组开始了解ASEILM,并希望将他们的数据与 其数据集成在•起。不能立即清楚地知道需要集成什么数据或集成数据的目的。也不清楚 要集成的数据的结构。在调査中，我们可以明显看出许多人都保持了数据的复本，这些数 据在某些方面属于ASEILM要跟踪的数据。为了使对支持额外数据类型的ASEILM的影 响最小，该小组滿要把定制组件中的数据抽象层与业务逻辑分离开。这能够使系统在不知 道数据存储的源或结构的情况下运行。图18.5给出了定制绀件的层。

 

并发一Java组件整体满足了 Miva组件整体未能满足的标准，但它同时也带来了关 于并发管理的新问题。通过开发模型解决方案，该小组认识到了 Java组件整体（不像Miva 组件整体）并不能管理并发。

 

Tomcat文档不讨论并发。为了确定这是否是一个关注点.该小组必须发现该组件整体 的线程模型。尤其是.他们必须了解IIS和Tomcat之间如何彼此相关.以及这将对系统产 生什么影响。他们对线程模型进行分析，并假定每个用户注册都产生了 •个不同的线程。 这建议了 3种情况：

 

• 两个用户同时访问该系统并使用不同的数据。当定制组件被划分为业务逻辑和数

 

据抽象层时，所制定的决策就是把适当的数据高速缓存在数据抽象层中。也就是 说.在初始化中.业务逻辑穿过数据袖象层从数据库中检索数据.并在业务逻辑 内维护。开发人员没有采取特殊的操作来使业务逻辑线程安全。因此.在两个用 户同时访问该业务逻辑的情况下.他们选择把业务逻辑当做关键部分来对待，用户按顺序访问所有业务逻辑。因为所有相关数据都柱留在内存中，所以满足每个 请求是•个快速的操作：只有当有很多用户同时提交请求时.对用户来说等待才 会变得不可容忍。在使用的环境中，预计只会有几个用户同时提交请求。

 

•    两个用户同时访问系统并使用相同的数据。该情况的•个方面——确保数据库中 的•致数据——是第-种情况的解决方案的副产品。因为对业务逻辑的访问是按 顺序进行的.因此，每次更新都是基于一•致的数据。这种情况的另一个方面是一 一用户可能会浏览和操作陈旧的数据——是使用HTTP把数据“推”给用户的问 题的表现。该小组决定把当前Web页面的定期重载构建到生成的HTML中，这 样.就保证了所浏览和操作的数据在一个规定的容许范围内是最新的。这并不是 最佳的解决方案，但它很容易实现，而且根据用户负载的期望，这大概已经足够了。

 

•    具有两个同时会话的•个用户。该小组拒绝了该选择。

 

该小组根据结朿评估的标准对该解决方案进行了评估，从最初用Miva进行试验以来， 这些标准就没有变过。Java servlet组件整体满足了该标准，实现继续进行下去。

 

结果证明java servlet组件整体解决方案适合该项目的黹要，在2002年初对ASEILM 系统进行了现场试验。耍想知道关于并发的使用模式的假设是否正确还为时过早，但早期 出现的迹象足积极的。然而，请注意该解决方案并不能很好地it行扩充。

 

18.5小 结

 

可以维持系统中的质最厲性，即使该系统主要是用其设计和交互机制不在设计师的掌 控之下的商业组件构建的也是如此。然而，在这种类型的系统中实现质麗属性要求的实践 与定制开发的代码有很大不同。需求过程需要更加灵活，允许在市场中可以获得的产品修 改需求.从而提供一个更佳的总体业务解决方案。需要确定基本需求，并在可行组件整体 的评估中将其作为个关键的限制引入。需要考虑多个偶然事件，因为基本需求的数量会 增多，难度会加大，因此必须将定制开发考虑为一种fallback。

 

18.6可进一步参阅的文献

 

本萆包含了从[Wallnau 02]中摘录的技巧和过程。如欲了解采用COTS时所存在的问 题.包括限制、.风险和移植，请访问网站

 

[Gar丨an 95]对构架不匹配以及从构架不匹配中恢复的技巧进行了更为详细的阐述。