200602281452595.html

软件工程的红包书

<P><FONT face=Verdana>模式名 <BR>环境 <BR>问题<BR>影响，描述应考虑的不同问题方面 <BR>解决方案<BR>基本原理 <BR>结果环境 <BR>示例 <BR>模式名<BR>层</FONT></P>
<P><FONT face=Verdana>环境<BR>需要进行结构分解的大系统。</FONT></P>
<P><FONT face=Verdana>问题<BR>必须处理不同抽象层次的问题的系统。例如：硬件控制问题、常见服务问题和针对于不同领域的问题。最好不要编写垂直构件来处理所有抽象层次的问题。否则要在不同的构件中多次处理相同的问题（可能会不一致）。</FONT></P>
<P><FONT face=Verdana>影响</FONT></P>
<P><FONT face=Verdana>系统的某些部分应当是可替换的 <BR>构件中的变化不应波动 <BR>相似的责任应归为一组 <BR>构件大小 -- 复杂构件可能要进行分解 <BR>解决办法<BR>将系统分成构件组，并使构件组形成层叠结构。使上层只使用下层（决不使用上层）提供的服务。尽量不使用非紧邻下层提供的服务（不跳层使用服务，除非<a href="200603101709095.html" tppabs="http://www.itisedu.com/phrase/200603101709095.html" target="_new">中间层</a>只添加通过构件）。</FONT></P>
<P><FONT face=Verdana>示例：</FONT></P>
<P align=center><FONT face=Verdana>1. 通用层</FONT></P><FONT face=Verdana>
<P align=center><IMG src="200641612272332.gif" tppabs="http://www.itisedu.com/manage/Upload/image/200641612272332.gif" border=0><BR></FONT>&nbsp;</P>
<P><FONT face=Verdana>严格的分层构架规定设计元素（类、构件、包、子系统）只能使用下层提供的服务， 服务可以包括事件处理、错误处理、数据库访问等等。&nbsp; 相对于记录在底层的原始<a href="200602281634075.html" tppabs="http://www.itisedu.com/phrase/200602281634075.html" target="_new">操作系统</a>级调用，它包括更明显的机制。</FONT></P>
<P align=center><FONT face=Verdana>2. 业务系统层</FONT></P>
<P align=center><FONT face=Verdana><IMG src="2006416122713848.gif" tppabs="http://www.itisedu.com/manage/Upload/image/2006416122713848.gif" border=0></FONT></P>
<P><FONT face=Verdana>上图显示了另一个分层示例，其中有垂直特定应用层、水平层和基础设施层。注意：此处的目标是采用非常短的业务“烟囱”并实现各种应用<a href="200604232224305.html" tppabs="http://www.itisedu.com/phrase/200604232224305.html" target="_new">程序</a>间的通用性。&nbsp; 否则，就可能有多个人解决同一问题，从而导致潜在的分歧。</FONT></P>
<P><FONT face=Verdana>有关该模式的深入讨论，请参见指南：分层。</FONT></P>
<P><FONT face=Verdana>模式名<BR>黑板</FONT></P>
<P><FONT face=Verdana>环境<BR>没有解决问题的确定方法（算法）或方法不可行的领域。例如 <a href="200604230831275.html" tppabs="http://www.itisedu.com/phrase/200604230831275.html" target="_new">AI</a> 系统、语音识别和监视系统。</FONT></P>
<P><FONT face=Verdana>问题<BR>多个问题解决顾问（知识顾问）必须通过协作来解决他们无法单独解决的问题。各顾问的工作结果必须可以供所有其他顾问访问，使他们可以评估自己是否可以参与解决方案的查找并发布其工作结果。</FONT></P>
<P><FONT face=Verdana>影响</FONT></P>
<P><FONT face=Verdana>知识顾问参与解决问题的顺序不是确定的，这可能取决于问题解决策略 </FONT></P>
<P><FONT face=Verdana>不同顾问的输入（结果或部分解决方案）可能有不同的表示方式 </FONT></P>
<P><FONT face=Verdana>各顾问并不直接知道对方的存在，但可以评估对方发布的工作 </FONT></P>
<P><FONT face=Verdana>解决办法<BR>多名知识顾问都可访问一个称为“黑板”的共享数据库。黑板提供监测和更新其内容的接口。控制模块/对象激活遵循某种策略的顾问。激活后，顾问查看黑板，以确定它是否能参与解决问题。如果顾问决定它可以参与，控制对象就可以允许顾问将其部分（或最终）解决方案放置于黑板上。</FONT></P>
<P align=center><FONT face=Verdana>示例：</FONT></P>
<P align=center><FONT face=Verdana><IMG src="2006416122738325.gif" tppabs="http://www.itisedu.com/manage/Upload/image/2006416122738325.gif" border=0></FONT></P>
<P><FONT face=Verdana>以上显示了使用 <a href="200602271429302.html" tppabs="http://www.itisedu.com/phrase/200602271429302.html" target="_new">UML</a> 建模的结构或静态视图。 它将成为参数化协作的一部分，然后会绑定到实参上对模式进行实例化。</FONT></P>
<P><FONT face=Verdana>构架风格 <BR>软件构架（或仅是构架视图）可以具有名为构架风格的属性，该属性减少了可选的形式，并使构架具有一定程度的一致性。样式可以通过一组模式或通过选择特定构件或连接器作为基本构件来定义。对给定系统，某些样式可作为构架描述的一部分记录在构架风格指南（Rational Unified Process 中设计指南文档的一部分）中。样式在构架的可理解性与完整性方面起着主要的作用。</FONT></P>
<P><FONT face=Verdana>构架设计图 <BR>构架视图的图形描述称为构架设计图。对于以上描述的各种视图，设计图由以下<a href="200604231300125.html" tppabs="http://www.itisedu.com/phrase/200604231300125.html" target="_new">统一建模语言</a>图组成 [UML99]： </FONT></P>
<P><FONT face=Verdana>逻辑视图：<a href="200603071659325.html" tppabs="http://www.itisedu.com/phrase/200603071659325.html" target="_new">类图</a>、状态机和<a href="200604161646065.html" tppabs="http://www.itisedu.com/phrase/200604161646065.html" target="_new">对象图</a>。 <BR>进程视图：类图与对象图（包括任务 - 进程与线程）。 <BR>实施视图：构件图。 <BR><a href="200604161237325.html" tppabs="http://www.itisedu.com/phrase/200604161237325.html" target="_new">部署视图</a>：<a href="200604241346445.html" tppabs="http://www.itisedu.com/phrase/200604241346445.html" target="_new">配置图</a>。 <BR>用例视图：<a href="200603071221195.html" tppabs="http://www.itisedu.com/phrase/200603071221195.html" target="_new">用例图</a>描述用例、主角和普通设计类；<a href="200604161949135.html" tppabs="http://www.itisedu.com/phrase/200604161949135.html" target="_new">顺序图</a>描述设计对象及其协作关系。 <BR>构架设计流程 <BR>在 Rational Unified Process 中，构架主要是分析设计<a href="200603110944215.html" tppabs="http://www.itisedu.com/phrase/200603110944215.html" target="_new">工作流</a>程的结果。当项目再次进行此工作流程时，构架将在一次又一次迭代中不断演化、改进、精炼。由于每次迭代都包括集成和测试，所以在交付产品时，构架就相当强壮了。构架是精化阶段各次迭代的重点，构架的<a href="200603130850315.html" tppabs="http://www.itisedu.com/phrase/200603130850315.html" target="_new">基线</a>通常会在此阶段结束时确定。<BR></FONT></P></FONT>
<P><FONT face=宋体>　　<B>架构师</B><BR><BR>　　<a href="200604232134505.html" tppabs="http://www.itisedu.com/phrase/200604232134505.html" target="_new">软体</a>设计师中有一些技术水平较高、经验较为丰富的人，他们需要承担软件系统的架构设计，也就是需要设计系统的元件如何划分、元件之间如何发生相互作用，以及系统中逻辑的、物理的、系统的重要决定的作出。<BR><BR>　　这样的人就是所谓的架构师（Architect）。在很多公司中，架构师不是一个专门的和正式的职务。通常在一个开发小组中，最有经验的程序员会负责一些架构方面的工作。在一个部门中，最有经验的项目经理会负责一些架构方面的工作。<BR><BR>　　但是，越来越多的公司体认到架构工作的重要性，并且在不同的组织层次上设置专门的架构师位置，由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。 </FONT></P>
<P></P>
<P><FONT face=宋体></FONT></P><!--Here is the bottom-->
<P><STRONG><FONT face=宋体 color=#ff0066>卡内基梅隆大学软件研究所关于软件架构的定义</FONT></STRONG></P></div>
</body>
</html>