📄 200604161433025.html

📁 软件工程的红包书
💻 HTML
字号:
<html>
<head><title>子系统</title></head>
<center><h1>子系统</h1></center>
<div><P align=right><FONT face=黑体 color=#ff0033><FONT face=Verdana><FONT color=#f70938><FONT face=黑体><a href="200604112229525.html" tppabs="http://www.itisedu.com/phrase/200604112229525.html" target="_new">中科永联</a>高级技术培训中心（</FONT><FONT face=黑体>www.itisedu.com</FONT><FONT face=黑体>）<IMG src="2006416143254163.jpg" tppabs="http://www.itisedu.com/manage/Upload/image/2006416143254163.jpg" border=0></FONT></FONT></FONT></FONT></P>
<P><FONT face=Verdana>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="200604161433025.html" tppabs="http://www.itisedu.com/phrase/200604161433025.html" target="_new">子系统</a>是一种模型元素，它具有包（其中可包含其他模型元素）和<a href="200603090857555.html" tppabs="http://www.itisedu.com/phrase/200603090857555.html" target="_new">类</a>（其具有行为）的语义。子系统的行为由它所包含的类或其他子系统提供。子系统实现一个或多个接口，这些接口定义子系统可以执行的行为。</FONT></P>
<P><FONT face=Verdana><STRONG>子系统的使用</STRONG> </FONT></P>
<P><FONT face=Verdana>可以通过多种互补的方法来使用子系统，将系统分为若干个单元，这些单元： </FONT></P>
<P><FONT face=Verdana>可以独立预定、配置或交付 <BR>可以独立开发（只要接口保持不变） <BR>可以在一组分布式计算节点上独立部署 <BR>可以在不破坏系统其他部分的情况下独立地进行更改 <BR>此外，子系统还可以： </FONT></P>
<P><FONT face=Verdana>将系统分为若干单元，以提供对关键资源的有限安全保护 <BR>在设计中代表现有产品或外部系统 </FONT></P>
<P><FONT face=Verdana><STRONG>从类协作中确定子系统</STRONG> </FONT></P>
<P><FONT face=Verdana>如果某个协作中的各个类只是在相互之间进行交互，并且可生成一组定义明确的结果，就应将该协作和它的类封装在一个子系统中。</FONT></P>
<P><FONT face=Verdana>这一规则同样适用于协作的子集。可以对协作的任何部分或全部进行封装和简化，这将会使设计更易于理解。</FONT></P>
<P><FONT face=Verdana>提示</FONT></P>
<P align=center>
<TABLE cellPadding=2 width="85%" border=1>
<TBODY>
<TR>
<TD vAlign=top borderColor=#808080 borderColorLight=#808080 width=216 borderColorDark=#808080 height=14>
<BLOCKQUOTE>
<P class=tableheading align=center>提示</P></BLOCKQUOTE></TD>
<TD vAlign=top borderColor=#808080 borderColorLight=#808080 width=440 borderColorDark=#808080 height=14>
<P class=tableheading align=center>详细说明</P></TD></TR>
<TR>
<TD vAlign=top borderColor=#808080 borderColorLight=#808080 width=216 borderColorDark=#808080 height=46>注意可选性</TD>
<TD vAlign=top borderColor=#808080 borderColorLight=#808080 width=440 borderColorDark=#808080 height=46>如果特定的协作（或子协作）代表可选行为，则应将其封装在一个子系统中。如果可以将某些功能删除、升级或替换为其他功能，就应该认为这些功能是独立的。</TD></TR>
<TR>
<TD vAlign=top borderColor=#808080 borderColorLight=#808080 width=216 borderColorDark=#808080 height=67 rowSpan=2>注意系统的用户界面。</TD>
<TD vAlign=top borderColor=#808080 borderColorLight=#808080 width=440 borderColorDark=#808080 height=34>如果用户界面相对独立于系统中的实体类（即二者都可以且将要独立地变更），则应创建横向集成的子系统：将相关的用户界面边界类归入一个子系统，而将相关的实体类归入另一个子系统。</TD></TR>
<TR>
<TD vAlign=top borderColor=#808080 borderColorLight=#808080 width=440 borderColorDark=#808080 height=33>如果用户界面和它所显示的实体类紧密耦合（即一方的变更会触发另一方的变更），则应创建纵向集成的子系统：将相关的边界类和实体类装入共同的子系统中。</TD></TR>
<TR>
<TD vAlign=top borderColor=#808080 borderColorLight=#808080 width=216 borderColorDark=#808080 height=50>注意主角</TD>
<TD vAlign=top borderColor=#808080 borderColorLight=#808080 width=440 borderColorDark=#808080 height=50>将两个不同主角使用的功能分开，因为每个主角可能会独立变更自己对系统的<a href="200603101518295.html" tppabs="http://www.itisedu.com/phrase/200603101518295.html" target="_new">需求</a>。</TD></TR>
<TR>
<TD vAlign=top borderColor=#808080 borderColorLight=#808080 width=216 borderColorDark=#808080 height=79>查找类与类之间的耦合和内聚</TD>
<TD vAlign=top borderColor=#808080 borderColorLight=#808080 width=440 borderColorDark=#808080 height=79>耦合度或内聚度较高的类彼此协作，以提供某一组服务。将耦合度较高的类组织成子系统，沿着弱耦合的界线将类分开。在某些情况下，可以将类分成更小的类，使其具有内聚度更高的职责，从而完全消除弱耦合。</TD></TR>
<TR>
<TD vAlign=top borderColor=#808080 borderColorLight=#808080 width=216 borderColorDark=#808080 height=19>注意替换</TD>
<TD vAlign=top borderColor=#808080 borderColorLight=#808080 width=440 borderColorDark=#808080 height=19>如果为某项特定功能指定了几个服务级别（例如，高、中、低可用性），则要将每个服务级别表示成一个独立的子系统，每个子系统都将实现同一组接口。这样，子系统就可互相替换。</TD></TR>
<TR>
<TD vAlign=top borderColor=#808080 borderColorLight=#808080 width=216 borderColorDark=#808080 height=35>注意分布</TD>
<TD vAlign=top borderColor=#808080 borderColorLight=#808080 width=440 borderColorDark=#808080 height=35>虽然一个特定子系统可能有多个实例，每个实例都在不同的节点上执行，但不可能在各节点间拆分子系统的单个实例。如果必须在各节点间拆分子系统行为，则需要将子系统分成更小的子系统，使其具有限制更严格的功能。确定必须存在于每个节点上的功能，并创建一个新的子系统，使其“拥有”该功能，然后相应地在该子系统内分布职责和相关元素。</TD></TR></TBODY></TABLE></P>
<P><FONT face=Verdana>一旦将类组织成子系统，就要相应地更新<a href="200604240937105.html" tppabs="http://www.itisedu.com/phrase/200604240937105.html" target="_new">用例</a>实现。</FONT></P>
<P><FONT face=Verdana><STRONG>记录子系统</STRONG> </FONT></P>
<P><FONT face=Verdana>一旦创建了子系统： </FONT></P>
<P><FONT face=Verdana>必须为每个子系统提供一个名称和一段简短说明。 <BR>如果工具支持包但不支持子系统，可以用包来记录子系统；在此环境中应使用包构造型 &laquo;subsystem&raquo; 表示子系统。 <BR>应将原始分析类的职责转移给新建的子系统，并使用该子系统的说明来记录职责。 </FONT></P>
<P><FONT face=Verdana><STRONG>子系统和<a href="200604161439595.html" tppabs="http://www.itisedu.com/phrase/200604161439595.html" target="_new">构件</a></STRONG> </FONT></P>
<P><FONT face=Verdana>构件属于实施范畴；为了在设计中表示构件，可以将子系统用作构件的代理。 </FONT></P>
<P><FONT face=Verdana>系统的每个部分都应尽可能独立于系统的其他部分。 <BR>从理论上说，应该可以用新的部分替换系统的任何部分，但前提是新部分必须支持相同的接口。 <BR>应该可以使系统的不同部分独立地演进，而不受系统其他部分的影响。 <BR>为此，设计子系统提供了一种在<a href="200604161258515.html" tppabs="http://www.itisedu.com/phrase/200604161258515.html" target="_new">设计模型</a>中表示构件的理想方法：它们是用来封装许多类的行为的设计元素（就象构件封装许多类实例的行为一样），并且只能通过它们所实现的接口访问它们的行为（构件就是这样）。</FONT></P>
<P><FONT face=Verdana><STRONG>代表现有产品的子系统</STRONG> </FONT></P>
<P><FONT face=Verdana>如果现有产品是用来导出接口（即操作，也许会导出接收）的产品，但却隐藏了实施的所有细节，就可以在<a href="200604161231275.html" tppabs="http://www.itisedu.com/phrase/200604161231275.html" target="_new">逻辑视图</a>中将该产品建模为子系统。您可以用子系统表示系统所使用的产品，例如： </FONT></P>
<P><FONT face=Verdana>通信<a href="200604232134205.html" tppabs="http://www.itisedu.com/phrase/200604232134205.html" target="_new">软件</a>（<a href="200604241155005.html" tppabs="http://www.itisedu.com/phrase/200604241155005.html" target="_new">中间件</a>）。 <BR><a href="200602271218062.html" tppabs="http://www.itisedu.com/phrase/200602271218062.html" target="_new">数据库</a>访问支持（RDBMS 映射支持）。 <BR>应用<a href="200604232224305.html" tppabs="http://www.itisedu.com/phrase/200604232224305.html" target="_new">程序</a>专用产品。 <BR>某些现有的产品，如<a href="200603051002565.html" tppabs="http://www.itisedu.com/phrase/200603051002565.html" target="_new">类型</a>集合和数据结构（例如，栈、列表、队列）最好用包来表示，因为它们所展示的不仅仅是行为。既重要又有用的是包中的特定内容，而不是包本身，包不过是一个容器而已。 </FONT></P>
<P><FONT face=Verdana>对于常用的实用程序（如数学库），如果它们只导出接口，就可以将其表示成子系统，但这是否有必要或有意义，还要取决于设计人员对建模<a href="200603090845215.html" tppabs="http://www.itisedu.com/phrase/200603090845215.html" target="_new">对象</a>性质的判断。子系统是<a href="200603101726185.html" tppabs="http://www.itisedu.com/phrase/200603101726185.html" target="_new">面向对象</a>的构造，它们不仅是分类器，还是包：子系统可以具有实例（如果设计人员作出这样的指定）。通过 <a href="200602271429302.html" tppabs="http://www.itisedu.com/phrase/200602271429302.html" target="_new">UML</a>，也可以在作为构造型类的实用程序（该实用程序没有实例）中建立多组全局变量和过程的模型。 </FONT></P>
<P><FONT face=Verdana>当定义子系统来代表产品时，还要定义一个或多个接口来表示产品接口。</FONT></P>
<P><FONT face=Verdana><STRONG>子系统依赖关系限制</STRONG> </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>子系统只应依赖于其他模型元素的接口，因此它不直接依赖于子系统外部的任何特定模型元素。例外情况是，许多子系统共享一组类定义。在这种情况下，这些子系统将“导入”包含公共类的包中的内容。这一操作只应对位于构架低层的包执行，并且只能是为了确保必须在子系统之间传递的公共类定义保持一致。 <BR>以下显示了子系统和包的依赖关系的示例：</FONT></P>
<P align=center><FONT face=Verdana><IMG src="2006416143229973.gif" tppabs="http://www.itisedu.com/manage/Upload/image/2006416143229973.gif" border=0></FONT></P>
<P align=center><FONT face=Verdana>设计模型中子系统和包的依赖关系</FONT><FONT face=Verdana><BR>&copy; 1987 - 2001 <a href="200604032121225.html" tppabs="http://www.itisedu.com/phrase/200604032121225.html" target="_new">Rational</a> Software Corporation。版权所有。 <BR></P></FONT></div>
</body>
</html>
⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -