《软件设计规范.docVIP

范围：CPU上可以识别的代码和数据。全部的代码总和。 要求：从定义开始的设计。完整性，彻底地定义从无开始的整个设计。这是因为软件之软，也是因为硬件平台的多样性和特殊性。 完整把握，从头设计是第一原则。因为软件世界自己并不能统一，还有继续分化的趋势。没有根本一致的基础可能是软件的本性。退回到一无所有是处理软件问题的根本。 在这样的视野下，操作系统只是一个部分，一个模块，不同的操作系统任你选择；语言的选择是运行环境的选择（每种语言有每种语言的运行时布局）；所谓框架只是“类库＋运行环境”的一种构造。 没有对其负载能力、操作强度进行评估前，这些东西（操作系统、语言、框架）还都不能纳入设计规范。 性能：运行过程的收敛（长时间运行的均态）。操作强度设计（串行处理速度），负载能力设计（并发处理的量）。可靠性设计。 软件问题的3个方面： 1、硬件，软件的操作对象和运行软件的数字系统（CPU系统和数字加速硬件） 2、交互操作（界面），专业界面设计 3、软件调度性能，实时的自动化过程（设备控制和自动测量）和用户交互过程（请求服务过程和干预过程；本地交互和远程交互），程控和网络访问的调度（服务器）。 软件项目的3个部分：（把3个阶段由纵向横过来，进行统筹） 分解文档，集成平台，可维护性要求。 软件设计必须有自说明特性。不能对文档产生依赖性。软件代码中合适的地方，需要对文档进行恰如其分说明。原则是，每段代码，每处需要理解的地方，如果和总体架构相关，就要有说明。 软件领域需要简化。需要还原软件本来的面目。EDA有泛滥的趋势，软件的各个方面都需要简化。软件形态、需求分析、文档说明、开发工具等。 需求分析过分强调适应生命周期的变化和没有需求分析是一样的。不切实际的面向未来的需求架构的直接结果是软件的复杂和错误百出。 软件只有一个，而观察的视角很多。要采用最适合的观察视角，让软件一目了然。 软件的生成过程和观察过程是两个不同的观念。生成过程又可以区分为：研究过程和工程过程。研究过程可以通过结果，研究报告反映；工程过程则必须采用过程刻画。 软件规范使用的语言一定要有普遍语义，但描述本身具有特殊性；不能强求它的全球唯一。一定要雄视全体，才能选择正确的立足点，这就要求对目前的软件技术有一个了解；要考虑纳入新的发展，那么规范应该分层，把一般的和具体易变的成分分开；要有具体的指导意义，越具体指导意义越大，但通用性则越小。 所谓架构，可能是十分具体应用的代表；不同类别的应用必然有不同的架构。软件架构本身是“应用架构”。因此，不能规范具体的架构。到是可以做：应用架构规范的规范。 逻辑架构的特殊性。可以判断，任何一款实用的软件采取的软件逻辑抽象都是别样的，特例的逻辑。否则，软件不可能那么轻快实用。软件逻辑，鬼魅也。而需求分析，必须是现实实用的，而不是同构/仿真的－这似乎是反对象分析的。因为这里强调的是和软件的交互界面，这个界面远远没有反映现实世界的结构。须知，软件强调的是数据处理，是输入输出。否则，就不能达到最简化。 可能现实世界的结构映射，最适合的方式是数据库 － 采用纯数据结构进行映射。除此之外，能有更合适的技术吗？ 面向对象建模是吗？那么对象又如何与现实世界的对象绑定在一起呢？ 这再次表明，在软件技术和需求分析之间有鸿沟。软件技术作为特殊的技术，有它的有限性。也反映了，包含软件应用在内的现实架构已经固定。 如果软件是数据处理，是输入输出，那么软件结构也就可以确定了！ 可视化、用户操作界面解开了另外的软件世界，因为可视化可以代表用户更抽象的逻辑。用户希望操作可视对象，象操作现实对象一样。软件从模拟现实对象的过程中继承了其结构。 工业控制也开启了新的软件世界，因为软件要从分离的输入建立“综合感知”，感知到设备状态，然后做出响应。 软件有其固有的物理属性，也就是计算的量。算法领域，无论算法的论证多么曲折，求得的结果，物化为软件，总是“早已熟知”的软件。这一区分，是定义软件规范的基石。 算法构造领域是和软件完全不同的领域，算法不是软件。算法类似数学系统。也一如数学系统那样多样。 软件构造。算法总要转化为软件，这就是软件构造问题。寻址系统，数组。软件把自己的生成作为问题，给算法开辟了新的领域。软件生成，是一个“构造－编译”问题。手工构造，自动编译。语言的发展，是一个软件生成的历史。所谓统一建模，所谓设计模式，其实都是软件生成的问题。 需求分析。需求分析本质上是独立的。所谓OOA，面向对象的建模，把程序构造概念上升到需求分析领域可能是不对的。一个先验的，复杂的难于掌握的限制，只会让人对需求分析望而却步；即使勉强掌握，难求对需求分析的创造性发展。需求分析应该专注于需求分析本身，独立发展，一切为了准确、快捷的分析。 需求分析层次高一些，抽象一些，自由一些，这样