20170311软件系统设计——06模块设计.docx

模块设计刘宏2017-03-11关于模块化设计，早在2005年就开发了相关的培训课件并实施培训。当时的培训课件时基于《软件工程——实践者的研究方法》开发的。目前看在方法上可以借鉴的。本文是更具培训课件内容编写的。软件设计既是过程又是模型。设计过程是一系列迭代的步骤，它们使设计者能够描述要构造的软件的所有侧面，然而，要注意的是，设计过程不仅仅是一本菜谱，创造性的技能、以往的经验、对于什么能形成“良好”软件的感觉、以及对质量的全部责任是设计成功的关键因素。设计基本原则基本的设计原则使软件工程师能够为设计过程导航。Davis提出了一系列软件设计的原则。下面的列表中对它们作了些修改和扩充：设计过程不应该受“隧道视野”的限制。一名好的设计者应该考虑替代的手段，根据问题的要求，可用13.4节提到的设计概念来判断完成工作的资源。设计对于分析模型应该是可跟踪的。因为设计模型的单独一个元素经常会跟踪到多个需求上，所以对设计模型如何满足需求进行的追踪是必要的。设计不应该从头做起。系统是使用一系列设计模式构造的，很多模式很可能在以前就遇到过。这些模式通常被称为可复用设计构件，应该总是作为一切都从头开始的方法的一种替代选择。时间短暂而资源有限！设计时间应该投入到表示真正的新思想和集成那些已有模式上去。设计应该缩短软件和现实世界中问题的“智力距离”[DAV95]。也就是说，软件设计的结构应该(尽可能)模拟问题域的结构。设计应该表现出一致性和集成性。如果一项设计整体上看上去象是一个人完成的，那它就是一致的。在设计工作开始之前，设计小组应该定义风格和格式的规则，如果注意定义了设计构件之间的接口，那么，设计就是集成的。设计应该构造以适应修改。下一节中讨论的许多概念使设计能实现这项原则。设计应该构造以使得即使遇到异常的数据、事件或操作条件时也能够平滑、轻巧地降级。设计良好的计算机程序应该从不“彻底崩溃”，它应该设计为适应异常的条件，并且即使它必须中止处理时，也要采用优雅的方式。设计不是编码，编码也不是设计。即使在为程序构件构造详细的过程设计时，设计模型的抽象级别也比源代码要高，在编码级别上作出的唯一设计决策是描述能使过程性设计被编码的小的实现细节。在创建设计时就应该能够评估质量，而不是在事情完成之后。有许多设计概念和设计方法可以帮助设计者评估质量。应该评审设计以减少概念性(语义性)错误。有时人们在复审设计中倾向于注重细节，只见树木不见森林。在关注设计模型的语法之前，设计者应该确保已经检查过设计的主要概念性元素(忽略、含糊性、不一致性)。在讲解设计的基本原则时，当时参加培训的人员提出一个使我非常困惑的问题：“软件的详细设计需要详细到什么程度？”这个问题具有非常现实的意义。记得当时没有回答出来。后来，经过大约四年的时间，在一个偶然的机会找到了此问题的答案。这个问题说明需要一定篇幅，若是有机会，这个问题答案将后续文章或者在培训课程中说明。何为“模块”与“模块化” 本文的主题是模块设计，需要明确何为模块？对于软件而言，我们习惯从功能角度描述模块。所以模块泛指软件系统的功能部件。在软件的体系结构设计完成之际，我们就已经确定了所有模块的功能，并且把模块们安放在体系结构的恰当位置上。模块的基本特征是“功能独立，并且可以被集成”。每个模块都具有特定的、明确的功能（否则不能成为模块）。人们在设计模块时应当尽量使模块的功能独立，因为功能独立的模块可以降低开发、测试、维护的代价。但是功能独立并不意味着模块是绝对孤立的。所有的模块应当能够被集成为一个系统，所以模块之间必定要交流信息、相互配合。比如手和脚是两个“功能独立”的模块。没有脚时，手照样能干活。没有手时，脚仍可以走路。但如果想让人跑得快，那么迈左脚时一定要伸右臂甩左臂，迈右脚时则要伸左臂甩右臂。所以在设计模块时不仅要考虑“这个模块应当有什么样的功能”，还要考虑“这个模块应该怎样与其它模块交流信息”。“模块化”（Modularization）是指：将系统分解为一系列功能模块，然后逐一实现这些模块，最后把所有的模块集成为原来的系统。这样做的好处是能够大大降低系统的开发难度。那么是否将系统分解得非常细、得到的功能模块越多越好呢？不是的。虽然这样做可以使实现模块的代价更低，但是把功能模块集成为原来系统的代价却增大了很多，得不偿失。图1模块花和软件成本当考虑模块化时，图1曲线为考虑模块化提供了有用的指导，我们应该进行模块化，但应注意保持在M附近，应该避免过低或过高的模块性。在考虑模块化时，出现了另一个重要问题：我们如何定义给定大小的一个合适模块？Meyer定义了五个标准，可以用于评价一种设计方法：模块可分解性。如果一种设计方法提供了将问题分解成子问题的系统化机制，它就能降低整个系统的复杂性，从而实现一种有效的模块化解决方案。模块可组装性