构件一般性制作指南【荐】.docVIP

构件一般性制作指南 一般性制作指南为创建具有最大复用潜力的软件提供指南，针对软件生命周期中的需求分析、设计、详细设计与实现、质量保证与测试以及文档等方面分别论述，帮助用户组织一个可复用软件构件（Reusable Software Component－RSC）的开发过程。这一部分的大部分内容独立于编程语言，在实现时采用特定语言的编码标准作为该标准的补充。 1 需求分析和领域分析 需求分析阶段为软件复用打下基础，此时对复用给予的关注将在相当大的程度上影响所开发软件的可复用性。主要应该在以下四个方面作出努力： (1) 建立一个鼓励复用现有软件的需求 需求规约必须认识到复用的必要性并鼓励软件复用。好的需求规约应该只规定所需的功能和性能指标，允许开发者决定操作上和实现上的细节。一个极端明细的规约是很难与任何现有软件相匹配的，不必要的系统需求将限制软件复用。将软件复用作为需求之一，在规约中规定所有必须的(Required)和期望的(Expected)复用活动。 (2) 将可复用软件的开发列入需求 如果希望所开发的系统是可复用的，就应该在需求中显式声明出来，并且应该使这种项目需求在客观上是可测试的。 (3) 领域分析的作用 领域分析活动不同于通常对特定系统进行的需求分析，它是对特定应用领域中已有的系统、预期的需求变化和技术演化进行分析，目的是标识出整个领域中通用的构架和相同的功能与接口。领域分析的结果将影响到系统需求的取舍，由此构造出的系统由于更适应变化的需求，日后被复用的可能性也更大。 2 概要设计原则 可复用性在很大程度上受到软件设计方法和设计决策的影响。可复用构件的设计至少应该满足构件的必要性、通用性、可变性、高效率(优化数据结构和算法、高效管理关键性资源)、健壮性、模块性、接口清晰、代码和数据易于移植、可演化、遵循命名惯例和软件体系结构惯例等等为实践验证过的原则。利用软件工程原则与方法进行RSC的概要设计主要涉及以下几个方面： (1) 从需求分析向设计转换 设计阶段应该支持此前建立的可复用需求，并为实现这些需求建立良好的框架。高层设计活动将不同需求划分给软件构架中的不同构件。这种分配必须保持需求的完整一致并便于向实现转换。这一活动的重要性在于就此标识并定义了需要建造的构件及其接口。等到详细设计阶段为特定的构件设计算法，实现RSC所应具有的通用性和易修改性。遵循详细设计指南，力求使RSC具有最大的通用性、灵活性和易修改性。 (2) 利用模型、构架和接口设计得到可复用的系统框架 模型用于声明软件需求，匹配需求与现有功能，完成从功能需求到实现决定的映射。良构的一致的模型是开发者与复用者之间的共同语言。模型应当对应于与真实世界中的概念，为提高可复用性再将模型进一步通用化。比如：用“填写表单”作为数据查询程序的用户界面的模型是易于理解的。再将表单中域的数目、位置和数据类型定义为可变参数，即得到更为通用的模型，由此创建出可复用性较高的构件。 用分层的构架来分离关注焦点，由此便隔离出了可复用子系统。分隔的各层可以被独立替换以便升级、移植和集成。一个给定层的下层为其上层定义了一个虚机器，相邻层次之间依靠特殊的预定义接口进行交互，不可跨层访问。比如：可以将数据库管理系统(DBMS)自上至下划分为数据操纵层、数据存取层、文件I/O层和物理设备层四层。应该适时地采用或符合现有的标准构架，如ISO－OSI参考模型。 为所有RSC划分并细化接口。接口应该清晰、简洁、干净。RSC的接口实际上是决定了复用该构件的系统所必须遵守的约束条件。在接口的文档中应该记录所有这些约束。应该根据“必要且充分”的准则进行接口设计，既要求提供充分的通用性和灵活性，又不能过分复杂而难以复用。这要求在简单性和通用性之间作出权衡。应该尽可能采用现有的标准接口（如采用SQL语言作为RDBMS的访问接口）。标准接口规约本身就是可复用的实体，因此应使之与设计规约中的其他成分相分离，并以方便复用的方式表示。 (3) 在设计时考虑RSC被修改的可能性 RSC有被修改后复用的可能。这可能是由于RSC的运行平台、OS、窗口系统或通信协议的改变，或者系统功能的扩充和协作构件的升级等原因；当RSC的生命周期较长时，往往有许多人维护、修改和改进过它，技术的演化也将导致对现有RSC的修改。在设计RSC时预见到可能的修改并采取相应的措施将大大提高其可复用性。 (4) 采用适当的软件设计方法 采用适当的设计方法能够有效地组织软件系统并提高个体构件的可复用性。应该将RSC封装为自包含的抽象实体，尽可能减少构件的外部依赖，在这方面OO方法能够更好的支持复用。传统的结构化功能分解方法强调构造低耦合、高内聚的模块，保持模块之间清晰的接口，但采用结构化方法时仍然应该注意贯彻抽象和封装的原则。 (5)