一个定义IEEE校准1471观点的方法

一个定义IEEE校准1471观点的方法———————————————————————————————————————————————————————————————摘要随着信息技术的越来越大的影响，对IT体系结构设计的适当的理解变得越来越重要。很多争论开始针对如何来描述他们，2000年，IEEE标准1471被提出作为一个体系结构描述的模型及其上下文。在这篇论文中，我们将提出一个在IEEE标准1471概念性的模型和定义IEEE标准1471观点之后的建模构架信息的轻量级方法。涉及利益相关者和结构信息的关系通过本文的形式以及图表的形式支持了该方法。对于观点的定义可以通过观察这些关系来完成。这个方法分为四个步骤：（1）创建利益相关者的轮廓（2）概述内不设计的文档（3）关联摘要以及利益相关者的利害关系以及（4）定义观点。我们已经在各种不同的设置中引导了一个讨论和在实践中检验的轮回。在这篇论文中我们将呈现出我们受到的反馈以及打算的改进。关键字：架构；IEEE标准1471；观点1．介绍IT架构是一个相对较新的软件工程的分支。IEEE标准1471（IEEE，2000）是这样定义的“架构是一个具体表达为各个成分的系统的基本的组织形式，他们彼此间的关系以及和环境和原理的关系指导它的设计以及发展”。VanVliet(2000)将架构定义阶段放置到软件生命周期中，位于需求分析和设计阶段之间。在这个阶段要考虑到利益以及涉及利益者的利害关系，由此来形成一个很均衡的解决方案。目前的实践就是IT框架的设计者必须是杰出的问题驱动。设计往往是一个模糊的，非理性的过程，看看Parnas和Clements（1986）但是在得到一个可以解决问题的平衡的解决方案之后，框架师就可以一结构化的方式来描述这个解决方案。这可以是古老的架构，也可以是出于一个像Kruchten(1995);Sonietal.(1995),或者Boar(1998)那些知名的框架结构。Clementsetal.(2003)提供了很多有用的模型和指导方针来构成一个框架的描述。多个股东用一份文档架构意味着这一个股东相关的信息可以分散开，看看Koning和vanVliet（为了出版而提交的）。2000年，IEEE标准1471提供了一个架构描述及其上下文的模型。它提供了一个高水平类的专注于利益相关者相关的架构描述模型。在这篇论文中我们将为这个模型的应用提供支持。这篇文章的组织如下：第二部分我们将陈述研究框架。第三部分我们给出了一个模型描述以及每一个步骤可行的实例。第四部分概述了确认行动并呈现了每一个步骤地结果。第五部分我们得出了结论提出了改进方法。第六部分总结了未来的工作。2．研究设置在这个部分我们将陈述研究设置。首先我们介绍IEEE标准1471并且我们对这个标准立场。之后我们将描述我们工程的方法。为了使这个部分紧凑，我们根据我们的方法所罗列了一些假设。2．1IEEE标准1471IEEE标准1471描述了一个框架描述（AD）及其上下文（IEEE，2000）的模型。在第一页，写着“这个推荐的实践的目的在于使框架的表达和交流变得更容易。”在第二页，“除此之外，它建立了一个概念和参考的术语的概念上的框架，这样系统框架技术未来的发展就可以展开了。这个推荐的实践规范了约定俗成的那些元素；确切的说，多重视图的使用，视图模型中可重用的规范，以及系统上下文的关系框架。”在IEEE1471概念模型中重要的“涉及到的术语”指的是“视图”，“观点”，“利益相关人”以及“利害关系”。一个“框架描述”包括每一个根据“观点”的多个“视图”根据概念的模型，一个股东由他的利害关系代表。一个视图是“从相关的利害关系集合出发的整个系统的一个代表”。一个观点是“一个构造和使用视图的协定的规范。一个模式或者模版用来通过建立一个视图的目标和听众以及它创建和分析所需要的技术发展一个独立的视图。”观点描述了呈现给利益相关人的框架信息。在一个方面一个观点指明了内容以及所要用到的“模型”，在另一方面，它指出了它的“利益相关者”和他们的“利益关系”。这个标准罗列了很多本质的利益相关者和利益关系，给出了应用了框架描述和一些观点的实例。这个标准没有为定义观点给出通常意义上的指导。它只是陈述了一个关于一系列相关利害关系的观点，而且所有的观点一起将覆盖所有利益相关人的利害关系。这里没有给出决定相关“关系”的标准。带有对我们的框架交流的兴趣地尊重，IEEE1471最重要的贡献就是对利益相关人和利害关系的清晰的指导方向。沿着它的公认的利害关系通过观点的指示的路径，一个利益相关者应该可以找到他在视图中感兴趣的信息。我们也相信这个标准存在一些缺陷，通过Koning和vanVliet（为了出版而提交）。我们感到IEEE标准1471应该用如何使文档质量对于利益相关人来说是“可以接近的”“易懂的”的指导思想来延伸。我们的研究着重于定义观点作为提高框架质量的支撑点，更特别的是要在决定应用那个观点之前改进对利益相关者的利害关系相关的洞察力。对这个方法的应用导致了IEEE1471中条款5。2和5。3的产生。它也可以被用来建造库观点或者评估现存的库观点如何应用到给定的情形中去。2．2工程方法图1：IEEE1471的关于体系架构描述的标准的概念的模型这个研究工程遵循一个“行动研究”方法，参见Baskerville(1999).在行为研究中定义了五个步骤：诊断，行动计划，获得行动，评估，指定学习。我们的关于四个真实生活的框架文档诊断显示出对于利益相关者是否能找到他们需要的信息的强烈的质疑。我们的行动计划导致了这篇文章所描述的设计IEEE1471中的观点的方法。我们获得行动就是讨论和小范围的测试。行动研究的参与者是两个公司的IT架构师，ING和Ordina,和来自我们学校的学生。ING是一个荷兰国际银行，它吸引了IT构架师来管理它的复杂的操作。全世界超过10000人在他们的IT部门工作，其中有几百个IT框架师。Ordina是一个IT咨询公司。它在管理和归档大型IT处理环境方面在几年的时间内发展出来一个视图。Ordina公共咨询拥有政府和市政部门的组织作为消费者。学生们都要学习一门关于软件体系结构的课程我们作为推荐人和调解人，积极地加入到这篇文章描述的讨论和测试会议中，在所有这些会议中，注释被写出并且共享给所有在场的人。2．3假设这篇文章所描述的方法基于如下假设：设计架构是一个含糊而且非理性的过程。为了交流的目的，结构的设计数据需要被构造（Parnas和Clements,1986）在设计框架工程的各个阶段都要进行归档框架。为了内部讨论，或者为了和利益相关者的中间讨论，部分问题陈述和经过深思熟虑的设计的解决方案被描述，修改，再描述。这些描述可以有不同程度的正式程度。从问题方向到解决方向要经过一个逐渐的改变。描述框架需要随机应变，意思就是说，它依赖于手头工程的特殊性。虽然尝试了很多去规范化架构描述，即规定一个固定的视图集，当前的实践是框架师，为不同的工程作出他们自己不同的选择。虽然因环境而异的方法很普遍，但是它并不是我们所期望的。在同样的观点可以复用的情况下，IEEE1471提供了可能作为库观点的存储和复用观点。以利益相关者的方向来描述的框架更适合利益相关者的阅读。更好的阅读性意味着：利益相关者可以更快地找到合资及相关的信息，它可以更容易的加工那些特殊的信息。文档的结构（视图的划分和各视图间的轮廓应与他相关）和文字和图的使用（文字和图应该对他有意义）决定了利益相关者方向。为了平衡他的利害关系，利益相关者所要考虑的视图数越烧越好。对于利益相关者来说，一个视图不相关的信息越少越好。只有在框架团队内部使用的信息不应该传递给利益相关者。一个利益相关者理解和评估一个IT框架基本上是一个把IT框架概念翻译成她自己概念的过程，然后推论出自IT框架引入后的可行的解决方法和结构。图表在IT框架交流中起到很重要的作用。图表很有作用因为它给出了组件和关系的全貌和推论的例证，参见Gyselinck和Tardieu（1998）。图表加快了处理信息的速度，他们帮助记住信息。有效的交流需要被设计。最基本的问题是：你想告诉谁什么？精确地（用文字或者图表）表达出一个人的想法给出了一个更好的观察，它能够导致正确的想法和更全面的设计。3．观点设计方法3.1介绍我们的设计观点的方法包括四个动作，原则上，在设计阶段结束，官方决定生效，以及交流发生之前完成。它包括一个已经想到，说过和写过的摘要，并且把它结构化了。如果需要，信息可以被添加来得到一个更完整的描述。在设计工程的最初阶段，一部分这种方法的应用将是可行的，而且我们确实希望它可以实行，但是测试的目的在于我们不愿意让事情此时变得过于繁杂。注意：我们现在就要提出“接近设计阶段末尾”的描述得到一些很直接的来自从业者的批判，甚至指有些细微的差别。他们的意见是：利益相关人和交流是贯穿整个设计工程的重点。参见我们进一步的“结论”部分。需要考虑的一个重要方面是这些执行的行为的细节水平。这可以限制将信息适当的聚合成以利益相关者的角度。这个方法用到的描述文本应该十分简洁，只需要设计者一个人懂。我们的建议是凭直觉执行这些动作，看看显现出什么画面，如果需要的话，一点点地去加入细节或者改进。执行的步骤如下：•步骤一：编译利益相关者的轮廓•步骤二：总结内部设计文档•步骤三：连接内部设计文档的概要和利益相关人的利害关系•步骤四：定义观点在图二中这些行为根据IEEE标准1471中的核心概念被放置。步骤1到3一起创建了一个框架描述的“文档设计试图”，它将被翻译成IEEE标准1471观点。主要的是，这些步骤在一些时间段在框架描述的本质内容和利益相关者的利害关系之间的关系方面为修补工作提供了一个方法。各种各样的工具被框架师用来表达和修改自己的想法，找到疏漏，找到表达关系的合适的词藻，等等。我们在下一个部分总结了这个方法应用在测试阶段。这个方法最初的描述，参见Koning（2003），包括了额外的步骤五“利益相关者的测试结果”和更多的细节，更多公开的建议和研究问题。当把方法呈现给测试者的同时，我们必须限制我们自己，并且着重于那些通过试图为聚集框架信息提供支持的这个方法的各个部分。这个方法描述的例子来自于ING目标框架工程。这里出现的问题是关于一个财政报告的条款，叫做“市场冒险”，数据被很多导致报告错误和高维修费用的系统操纵。另外一个额外的观点实例来自一个学生的作业。图2.设计观点的方法，根据IEEE标准1471的主要概念放置3.2步骤一：编辑利益相关者的轮廓在这个步骤中，每一个和这个框架设计有联系利益相关者的“利益相关者的轮廓”都将被编辑。一个利益相关者的轮廓就是一个简单的表格，包括了五个属性的描述文本：标题，目标，任务，概念，利害关系。这个行为的目的在于使利益相关者的地位清晰，并且可以了解他需要知道的信息。这个表格从来利益相关者的角度表述了如何架构。这是一个利益相关者的位置的浓缩概述，参见表1。显示出新的信息不是目的，但是这个动作确实可以显示出丢失的信息。如果的确如此，可以采取行动来补给这个信息。这些属性的选择的灵感来源于一些书籍，包括需求工程（Kotonya和Sommerville，1998）和用户接口设计（vanWelie，2001）。参见表2作为一个利益相关者轮廓的实例当提出了利益相关者轮廓的数量，我们要考虑5个属性有良好的平均。为了更好的理解，一个利益相关人可以考虑两个轮廓。一个概要的轮廓用来表述利益相关者在组织中的位置，另外一个表述了对框架的位置。IEEE1471，5.2条款提到了至少应该考虑的一些利益相关人和利害关系。在下一个阶段，利益相关人的轮廓可以继续调整和发展。表1：利益相关人的轮廓的属性表2：利益相关人轮廓的实例3.3步骤2：概述内部设计文档在这个步骤中可行的内部的文档将被概括（如果还没有做）。内部设计文档的提法的意思就是在项目进行中，设计团队内部交流的信息记录也是目前设计的一部分。这个信息可以根据一些正式的标准来结构化，这全要取决于设计者。目的是产生出一个架构信息的观点，来把这些信息和