文章目录

• • 结构化方法
  • Jackson方法
  • 原型方法
  • 面向对象方法
  • 敏捷方法
  • 水晶法
  • 并列争求法
  • 自适应软件开发（ASD)
• 软件设计的演变过程
• • 序言
  • 结构化程序设计
  • 面向对象程序设计
  • 设计模式
  • 设计原则
  • 领域驱动设计
  • DCI架构模式
  • 领域专用语言
  • 微服务架构模式
  • 小结
• 软件设计模式——七大设计原则
• • 7种开发原则
  • • 开闭原则
    • 里氏替换原则
    • 依赖倒置原则
    • 单一职责原则
    • 接口隔离原则
    • 迪米特法则
    • 合成复用原则
  • 总结
  • 参考
• 软件设计方法
• • 一 简介
  • 二（软件）设计是什么/li>
  • 三 设计过程
  • 四（软件）设计基础
  • 五（软件）设计方法论*
  • 六（软件）设计文档
  • 七 面向对象的（软件）设计

已剪辑自: https://zhuanlan.zhihu.com/p/50382755

软件开发方法是一种使用早已定义好的技术集及符号表示习惯，来组织软件生产的过程。

软件开发需要严谨工作方法。软件开发的方法有很多，不同的开发方法适用于不同的软件项目，具体使用哪种方法，还需要根据软件情况来确定。

结构化方法

结构化方法由结构化分析、结构化设计、结构化程序设计构成，它是一种面向数据流的开发方法。

结构化分析

是根据分解与抽象的原则，按照系统中数据处理的流程，用数据流图来建立系统的功能模型，从而完成需求分析工作。

结构化设计

根据模块独立性准则、软件结构优化准则将数据流图转换为软件的体系结构，用软件结构图来建立系统的物理模型，实现系统的概要设计。

结构化程序设计

使用3种基本控制结构构造程序，任何程序都可以由顺序、选择和重复3种基本控制结构构造。

结构化方法总的指导思想是自顶向下、逐层分解，它的基本原则是功能的分解与抽象。适合于数据处理领域的问题，不适合解决大规模的、特别复杂的项目，且难以适应需求的变化。

Jackson方法

Jackson方法是一种面向数据结构的开发方法。

JSP(JacksonStructure Programming）方法是以数据结构为驱动的，适合于小规模的项目。JSP方法首先描述问题的输入/输出数据结构，分析其对应性，然后推出相应的程序结构，从而给问题的软件过程描述。

JSD方法是JSP方法的扩展，是一个完整的系统开发方法。首先建立现实世界的模型，再确定系统的功能需求，对需求的描述特别强调操作之间的时序性。它是以事件作为驱动的，是一种基于进程的开发方法，所以适用于时序特别较强的系统，包括数据处理系统和一些实时控制系统。

原型方法

原型方法比较适合于用户需求不清、需求经常变化的情况。当系统规模不是很大也不太复杂时，采用该方法比较好。

面向对象方法

面向对象方法正是以对象作为最基本的元素，它也是分析问题、解决问题的核心。面向对象方法包括面向对象分析、面向对象设计和面向对象实现。

UML是面向对象的标准建模语言，通过统一的语义和符号表示，使各种方法的建模过程和表示统一起来，现已成为面向对象建模的工业标准。

敏捷方法

极限编程(XP)：XP是一种轻量级（敏捷）、高效、低风险、柔性、可预测的、科学的软件开发方式。它由价值观、原则、实践和行为4个部分组成，彼此相互依赖、关联，并通过行为贯穿于整个生存周期。

4大价值观：沟通、简单性、反馈、勇气

5个原则：快速反馈、简单性假设、逐步修改、提倡更改、优质工作

12个最佳实践：计划游戏（快速制定计划、随着细节的不断变化而完善）、小型发布（系统的设计要能够尽可能早地交付）、隐喻（找到合适的比喻传达信息）、简单设计（只处理当前的需求，使设计保持简单）、测试先行（先写测试代码，然后再编写程序） 、重构（重新审视需求和设计，重新明确地描述他们以符合新的和现有的需求）、结对编程、集体代码所有制、继续集成（可以按日甚至按小时为客户提供可运行的版本）、每周工作40小时、现场客户和编码标准。

水晶法

水晶法认为每一个不同的项目都需要一套不同的策略、约定和方法论。

并列争求法

并列争求法使用迭代的方法，其中，把每30天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。

自适应软件开发（ASD)

ASD有6个基本的原则

• 有一个使命作为指导；
• 特征被视为客户价值的关键点；
• 过程中的等待是很重要的，因此“重做”与“做”同样关键
• 变化不被视为改正，而是被视为对软件开发实际情况的调查。
• 确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求。
• 风险也包含其中。

---

软件设计的演变过程

已剪辑自: https://www.jianshu.com/p/18d1d582f5c2

“Design is there to enable you to keep changing the software easily in the long term” —— Kent Beck

tranditional-method.png

分析模型和设计模型的分离，会导致分析师头脑中的业务模型和设计师头脑中的业务模型不一致，通常要映射一下。伴随着重构和bug fix的进行，设计模型不断演进，和分析模型的差异越来越大。有些时候，分析师站在分析模型的角度认为某个需求较容易实现，而设计师站在设计模型的角度认为该需求较难实现，那么双方都很难理解对方的模型。长此以往，在分析模型和设计模型之间就会存在致命的隔阂，从任何活动中获得的知识都无法提供给另一方。

Eric Evans在2004年出版了领域驱动设计（DDD, Domain-Driven Design）的开山之作《领域驱动设计——软件核心复杂性应对之道》，抛弃将分析模型与设计模型分离的做法，寻找单个模型来满足两方面的要求，这就是领域模型。许多系统的真正复杂之处不在于技术，而在于领域本身，在于业务用户及其执行的业务活动。如果在设计时没有获得对领域的深刻理解，没有通过模型将复杂的领域逻辑以模型概念和模型元素的形式清晰地表达出来，那么无论我们使用多么先进、多么流行的平台和设施，都难以保证项目的真正成功。

领域驱动设计分为两个阶段：

1. 以一种领域专家、设计人员和开发人员都能理解的通用语言作为相互交流的工具，在交流的过程中发现领域概念，然后将这些概念设计成一个领域模型；
2. 由领域模型驱动软件设计，用代码来表达该领域模型。

由此可见，领域驱动设计的核心是建立正确的领域模型。

领域专家、设计人员和开发人员一起创建一套适用于领域建模的通用语言，通用语言必须在团队范围内达成一致。所有成员都使用通用语言进行交流，每个人都能听懂别人在说什么，通用语言也是对软件模型的直接反映。领域专家、设计人员和开发人员一起工作，这样开发出来的软件能够准确的表达业务规则。领域模型基于通用语言，是关于某个特定业务领域的软件模型，如下图所示：

ddd-layer.png

1. User Interface为用户界面/展现层，负责向用户展现信息以及解释用户命令。
2. Application为应用层，是很薄的一层，定义软件要完成的所有任务。对外为展现层提供各种应用功能（包括查询或命令），对内调用领域层（领域对象或领域服务）完成各种业务逻辑，应用层不包含业务逻辑。
3. Domain为领域层，负责表达业务概念，业务状态信息以及业务规则，领域模型处于这一层，是业务软件的核心。
4. Infrastructure层为基础实施层，向其他层提供通用的技术能力；提供了层间的通信；为领域层实现持久化机制；总之，基础设施层可以通过架构和框架来支持其他层的技术需求。

DCI架构模式

James O. Coplien和Trygve Reenskaug在2009年发表了一篇论文《DCI架构：面向对象编程的新构想》，标志着DCI架构模式的诞生。有趣的是James O. Coplien也是MVC架构模式的创造者，这个大叔一辈子就干了两件事，即年轻时创造了MVC和年老时创造了DCI，其他时间都在思考，让我辈望尘莫及。
面向对象编程的本意是将程序员与用户的视角统一于计算机代码之中：对提高可用性和降低程序的理解难度来说，都是一种恩赐。可是虽然对象很好地反映了结构，但在反映系统的动作方面却失败了，DCI的构想是期望反映出最终用户的认知模型中的角色以及角色之间的交互。

传统上，面向对象编程语言拿不出办法去捕捉对象之间的协作，反映不了协作中往来的算法。就像对象的实例反映出领域结构一样，对象的协作与交互同样是有结构的。协作与交互也是最终用户心智模型的组成部分，但你在代码中找不到一个内聚的表现形式去代表它们。在本质上，角色体现的是一般化的、抽象的算法。角色
没有血肉，并不能做实际的事情，归根结底工作还是落在对象的头上，而对象本身还担负着体现领域模型的责任。
人们心目中对“对象”这个统一的整体却有两种不同的模型，即“系统是什么”和“系统做什么”，这就是DCI要解决的根本问题。用户认知一个个对象和它们所代表的领域，而每个对象还必须按照用户心目中的交互模型去实现一些行为，通过它在用例中所扮演的角色与其他对象联结在一起。正因为最终用户能把两种视角合为一体，类的对象除了支持所属类的成员函数，还可以执行所扮演角色的成员函数，就好像那些函数属于对象本身一样。换句话说，我们希望把角色的逻辑注入到对象，让这些逻辑成为对象的一部分，而其地位却丝毫不弱于对象初始化时从类所得到的方法。我们在编译时就为对象安排好了扮演角色时可能需要的所有逻辑。如果我们再聪明一点，在运行时知道了被分配的角色，才注入刚好要用到的逻辑，也是可以做到的。

算法及角色-对象映射由Context拥有。Context“知道”在当前用例中应该找哪个对象去充当实际的演员，然后负责把对象“cast”成场景中的相应角色。（cast 这个词在戏剧界是选角的意思，此处的用词至少符合该词义，另一方面的用意是联想到cast 在某些编程语言类型系统中的含义。）在典型的实现里，每个用例都有其对应的一个Context 对象，而用例涉及到的每个角色在对应的Context 里也都有一个标识符。Context 要做的只是将角色标识符与正确的对象绑定到一起。然后我们只要触发Context里的“开场”角色，代码就会运行下去。
于是我们有了完整的DCI架构（Data、Context和Interactive三层架构）：

1. Data层描述系统有哪些领域概念及其之间的关系，该层专注于领域对象和之间关系的确立，让程序员站在对象的角度思考系统，从而让“系统是什么”更容易被理解。
2. Context层：是尽可能薄的一层。Context往往被实现得无状态，只是找到合适的role，让role交互起来完成业务逻辑即可。但是简单并不代表不重要，显示化context层正是为人去理解软件业务流程提供切入点和主线。
3. Interactive层主要体现在对role的建模，role是每个context中复杂的业务逻辑的真正执行者，体现“系统做什么”。Role所做的是对行为进行建模，它联接了context和领域对象。由于系统的行为是复杂且多变的，role使得系统将稳定的领域模型层和多变的系统行为层进行了分离，由role专注于对系统行为进行建模。该层往往关注于系统的可扩展性，更加贴近于软件工程实践，在面向对象中更多的是以类的视角进行思考设计。

DCI目前广泛被作为对DDD的一种发展和补充，用于基于面向对象的领域建模。显示的对role进行建模，解决了面向对象建模中充血和贫血模型之争。DCI通过显示的用role对行为进行建模，同时让role在context中可以和对应的领域对象进行绑定(cast)，从而既解决了数据边界和行为边界不一致的问题，也解决了领域对象中数据和行为高内聚低耦合的问题。

面向对象建模面临的一个棘手问题是数据边界和行为边界往往不一致。遵循模块化的思想，我们通过类将行为和其紧密耦合的数据封装在一起。但是在复杂的业务场景下，行为往往跨越多个领域对象，这样的行为放在某一个对象中必然导致别的对象需要向该对象暴漏其内部状态。所以面向对象发展的后来，领域建模出现两种派别之争，一种倾向于将跨越多个领域对象的行为建模在领域服务中。这种做法使用过度经常导致领域对象变成只提供一堆get方法的哑对象，这种建模导致的结果被称之为贫血模型。而另一派则坚定的认为方法应该属于领域对象，所以所有的业务行为仍然被放在领域对象中，这样导致领域对象随着支持的业务场景变多而变成上帝类，而且类内部方法的抽象层次很难一致。另外由于行为边界很难恰当，导致对象之间数据访问关系也比较复杂。这种建模导致的结果被称之为充血模型。

DCI和袁英杰大师提出的“小类大对象”殊途同归，即类应该是小的，对象应该是大的。上帝类是糟糕的，但上帝对象却恰恰是我们所期盼的。而从类到对象，是一种多对一的关系：最终一个对象是由诸多单一职责的小类——它们分别都可以有自己的数据和行为——所构成。而将类映射到对象的过程，在Ruby中通过Mixin；在Scala中则通过Traits；而C++则通过多重继承。

举个生活中的例子:

人有多重角色，不同的角色履行的职责不同:

1. 作为父母：我们要给孩子讲故事，陪他们玩游戏，哄它们睡觉；
2. 作为子女：我们则要孝敬父母，听取他们的人生建议；
3. 作为下属：在老板面前，我们需要听从其工作安排；
4. 作为上司：需要安排下属工作，并进行培养和激励；
5. …

这里人（大对象）聚合了多个角色（小类），在某种场景下，只能扮演特定的角色：

1. 在孩子面前，我们是父母；
2. 在父母面前，我们是子女；
3. 职场上，在上司面前，我们是下属；
4. 在下属面前，你是上司
5. …

对于通信系统软件，没有UI层，应用层也很薄，所以传统的DDD的四层模型并不适用。DCI提出后，针对通信系统软件，我们将DDD的分层架构重新定义一下，如下图所示：

transaction-dsl.png

有了transaction DSL之后，针对通信系统软件的DDD四层模型可以演进为五层模型，如下图所示：

monoliths-and-microservices.png

微服务是指开发一个单个小型的但有业务功能的服务，可以选择自己的技术栈和数据库，可以选择自己的通讯机制，可以部署在单个或多个服务器上。这里的“微”不是针对代码行数而言，而是说服务的范围不能大于DDD中的一个BC（Bounded Context，限界上下文）。

微服务架构模式的优点：

1. 微服务只关注一个BC，业务简单
2. 不同微服务可由不同团队开发
3. 微服务是松散耦合的
4. 每个微服务可选择不同的编程语言和工具开发
5. 每个微服务可根据业务逻辑和负荷选择一个最合适的数据库

微服务架构模式的挑战：

1. 分布式系统的复杂性，比如事务一致性、网络延迟、容错、对象持久化、消息序列化、异步、版本控制和负载等
2. 更多的服务意味着更高水平的DevOps和自动化技术
3. 服务接口修改会波及相关的所有服务
4. 服务间可能存在重复的功能点
5. 测试更加困难

尽管微服务架构模式对“个子”的要求比较高，但随着容器云技术的不断成熟，微服务架构模式却越来越火，似乎所有系统的架构都在尽情拥抱微服务，这是不是意味着单体架构模式不再是我们的选择了呢者认为需要根据具体情况而定，我们看看下面这张图：

microservice-premium.png

上图直观的说明了单体架构和微服务架构在不同系统复杂度下不同的生产力，以及两者的对比关系。对于那种需要快速为商业模式提供验证的系统，在其功能较少和用户量较低的情况下，单体架构模式是更好的选择，但在单体架构内部，需要清晰的划分功能模块，尽量做到高内聚低耦合。

总而言之，微服务架构有很多吸引人的地方，不过在拥抱微服务之前要认清它所带来的挑战。每一种架构模式都有其优缺点，我们需要根据项目和团队的实际情况来选择最合适的架构模式。

小结

本文较为详细的阐述了软件设计的演变过程，包括结构化程序设计、面向对象程序设计、设计模式、设计原则、DDD、DCI、DSL和微服务架构模式，通过对这些设计思想的全面梳理，可以帮助我们做出更好的设计决策。

---

软件设计模式——七大设计原则

已剪辑自: https://hjk.life/posts/design-patterns-principles/

• 概述

  设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。

  描述了在软件设计过程中的一些不断重复发生的问题，以及该问题的解决方案。

  是解决特定问题的一系列套路，是前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使用。

  其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。

• 作用

  • 提高思维能力、编程能力和设计能力。
  • 使程序设计更加标准化、代码编制更加工程化，使软件开发效率大大提高，从而缩短软件的开发周期。
  • 使设计的代码可重用性高、可读性强、可靠性高、灵活性好、可维护性强。

7种开发原则

开闭原则

• 定义

  • 软件实体应当对扩展开放，对修改关闭。即, 当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。

• 作用

  • 对软件测试的影响

    测试时只需要对扩展的代码进行测试就可以了，因为原有的测试代码仍然能够正常运行。

  • 提高代码的可复用性

    粒度越小，被复用的可能性就越大；在面向对象的程序设计中，根据原子和抽象编程可以提高代码的可复用性。

  • 提高软件的可维护性

    稳定性高和延续性强，从而易于扩展和维护。

里氏替换原则

• 定义
  • 继承必须确保基类所拥有的性质在子类中仍然成立。即, 子类可以扩展父类的功能，但不能改变父类原有的功能。
• 作用
  • 是实现开闭原则的重要方式之一。
  • 克服了继承中重写父类造成的可复用性变差的缺点。
  • 类的扩展不会给已有的系统引入新的错误，降低了代码出错的可能性。

依赖倒置原则

• 定义
  • **要面向接口编程，不要面向实现编程。**即, 高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。
• 作用
  • 可以降低类间的耦合性。
  • 可以减少并行开发引起的风险。
  • 可以提高代码的可读性和可维护性。

单一职责原则

• 定义
  • 单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。
  • 如果一个对象承担了太多的职责，至少存在以下两个缺点
    • 一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力；
    • 当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。
• 作用
  • 降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。
  • 提高类的可读性。复杂性降低，自然其可读性会提高。
  • 提高系统的可维护性。可读性提高，那自然更容易维护了。
  • 变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。

接口隔离原则

• 定义
  • 客户端不应该被迫依赖于它不使用的方法
  • 一个类对另一个类的依赖应该建立在最小的接口上
  • 与单一职责原则的区别
    • 单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。
    • 单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。
• 作用
  • 将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
  • 接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性。
  • 使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。
  • 能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码。

迪米特法则

• 定义
  • , 又叫作最少知识原则（)
  • 如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。
• 作用
  • 降低了类之间的耦合度，提高了模块的相对独立性。
  • 由于亲合度降低，从而提高了类的可复用率和系统的扩展性。

合成复用原则

• 定义

  • , 又叫组合/聚合复用原则（）。
  • 在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。

• 作用

  • 通常类的复用分为

    继承复用

    和

    合成复用

    两种，继承复用虽然有简单和易实现的优点，但它也存在以下缺点:

    • 继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类，父类对子类是透明的，所以这种复用又称为“白箱”复用。
    • 子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化，这不利于类的扩展与
    • 它限制了复用的灵活性。从父类继承而来的实现是静态的，在编译时已经定义，所以在运行时不可能发生变化。

  • 采用组合或聚合复用时，可以

    将已有对象纳入新对象中，使之成为新对象的一部分，新对象可以调用已有对象的功能

    ，它有以下优点:

    • 它维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用。
    • 新旧类之间的耦合度低。这种复用所需的依赖较少，新对象存取成分对象的唯一方法是通过成分对象的接口。
    • 复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象。

总结

设计原则一句话归纳目的

开闭原则	对扩展开放，对修改关闭	降低维护带来的新风险
依赖倒置原则	高层不应该依赖低层，要面向接口编程	更利于代码结构的升级扩展
单一职责原则	一个类只干一件事，实现类要单一	便于理解，提高代码的可读性
接口隔离原则	一个接口只干一件事，接口要精简单一	功能解耦，高聚合、低耦合
迪米特法则	不该知道的不要知道，一个类应该保持对其它对象最少的了解，降低耦合度	只和朋友交流，不和陌生人说话，减少代码臃肿
里氏替换原则	不要破坏继承体系，子类重写方法功能发生改变，不应该影响父类方法的含义	防止继承泛滥
合成复用原则	尽量使用组合或者聚合关系实现代码复用，少使用继承	降低代码耦合

实际上，这些原则的目的只有一个：降低对象之间的耦合，增加程序的可复用性、可扩展性和可维护性。

记忆口诀：访问加限制，函数要节俭，依赖不允许，动态加接口，父类要抽象，扩展不更改。

在程序设计时，我们应该将程序功能最小化，每个类只干一件事。若有类似功能基础之上添加新功能，则要合理使用继承。对于多方法的调用，要会运用接口，同时合理设置接口功能与数量。最后类与类之间做到低耦合高内聚。

参考

---

软件设计方法

已剪辑自: https://www.cnblogs.com/bastard/archive/2011/11/30/2269587.html

（软件）设计方法 装载自：http://www.chinaunix.net/jh/28/70767.html
作者:Larry Brinn 翻译: CKER
1. 简介
2. （软件）设计是什么br> 3. （软件）设计过程
4. （软件）设计基础
5. （软件）设计方法论
6. （软件）设计文档
7. 面向对象的（软件）设计
8. 结论

一 简介

1您是如何开始一个新工程的不是跳到计算机前，打开您喜爱的 RAD 工具开始输入代码/p>

2有没有想过程序会执行些什么或者系统是如何操纵数据的/p>

3有没有想过要记下些东西来帮助提醒您或阐明您已经开发的代码的逻辑实现果您对第一个问题答”不”，而其他问题答”是”的话，您可以跳过这篇文档。否则的话，请好好读读 这篇文章。

您应该有个计划、蓝图，并且在手边有个对您的问题解决方案的简明安排。您必须知道您要去哪儿得到一切！让我们来看看开发一个能实现您所设计的功能的程序时，什么最棘手。

二（软件）设计是什么/h2>

E.S. Taylor 给设计下的定义是 :
” …the process of applying various techniques and principles for the purpose of defining a device,

a process or a system in sufficient detail to permit its physical realization. “
” … 应用各种各样的技术和原理，并用它们足够详细的定义一个设备、一个程序或系统的物理实现的过程。 “

对任意的工程产品或系统，开发阶段绝对的第一步是确定将来所要构建的制造原型或实体表现的目标构思。

这个步骤是由多方面的直觉与判断力来共同决定的。

这些方面包括构建类似模型的经验、一组引领模型发展的原则、一套启动质量评价的标准、以及重复修改直至设计最后定型的过程本身。

计算机软件设计与其他工程学科相比还处在幼年时期，仍在不断变化中，

例如更新的方法、更好的算法分析、以及理解力的显著进化。软件设计的方法论的出现也只有三十年多一点，

仍然缺乏深度、适应性和定量性质，通常更多的与经典工程设计学科相联系。

尽管如此，现今的软件技术已经存在、设计质量的标准也可使用、设计符号亦可以应用。

带着这些意见，我们一起来看看什么有助于程序员们找到他们的软件涅盘 ( 天堂的意思 ) 。

三 设计过程

软件的设计是一个将需求转变为软件陈述（表达）的过程。这种陈述给我们一个对软件的全局观点。

系统通过逐步求精使得设计陈述逐渐接近源代码。这里有两个基本步骤；

第一步是 初步设计 Preliminary design ，关注于如何将需求转换成数据和软件框架。

第二步是 详细设计 Detail design ，关注于将框架逐步求精细化为具体的数据结构和软件的算法表达。

发生中的设计行为、数据、算法和程序设计都需要由现代程序所需的界面设计这一清晰的行为来结合起来。

界面设计 Interface design 建立程序布局和人机交互机制。

贯穿设计过程的质量由一系列的 正式技术评定 formal technical reviews 或 设计排演 design walkthroughs 来评价。

良好的设计规范必须建立在对设计陈述（表达）的评估之上，以下是一些指导方针：

1. 设计应该展现层次结构使得软件各部分之间的控制更明智。

2. 设计应当模块化；这就是说，软件应在逻辑上分割为实现特定的功能和子功能的部分。

3. 设计应当由清晰且可分离的数据和过程表达来构成。

4. 设计应使得模块展现独立的功能特性。

5. 设计应使得界面能降低模块之间及其与外部环境的连接复杂性。

6. 设计应源自于软件需求分析期间获得的信息所定之可重复方法的使用。

要拥有良好的设计特征不是靠碰运气，而在设计过程中通过综合运用基础设计原理、系统方法论、彻底的评定回顾可以有助于良好的设计。

软件设计方法每天都在进化，作为已经经过测试和细化的方法，良好的设计应具有以下的四种特性，并在所有这些特性之间保持一致。

1. 将信息领域的表达转换为软件设计的表达的机制。

2. 表示功能组件及其界面的符号。

3. 逐步求精和分割的试探。

4. 质量评估的指导方针。

开发软件的时候，不管采用何种设计方法您必须能够熟练运用一套关于数据、算法和程序设计的基本原理。

四（软件）设计基础

软件设计方法论的这套基本原理已经经过了多年的进化。每种概念的影响程度不尽相同，但它们都经历了时间的洗礼。

基于这些基本原理设计者可以采用更多更成熟的设计方法。这些基本原理有助于设计者回答以下的问题：

1. 将软件分割成独立的组件时会采用何种标准/p>

2. 怎样将软件的原则性表示详细分割成函数或数据结构/p>

3. 有没有定义一个软件设计的技术质量的统一标准/p>

M.A. Jackson 曾经说过： ” 对一个计算机程序员来说，分辨让程序运行和让程序 正确 之间的差异是一个良好的开端。

” 为了 ” 使程序 正确 ” ，基本设计原理提供了必须的框架。因此让我们来对这些基本原理作个简短的检视。

1****抽象 Abstraction

在最高层次上指的是使用待解决的问题领域内的术语描述的解决方案。相对较低层次的抽象则更多的面向程序语言，

最低层的抽象则是解决方案的可直接实现的方式描述。软件设计的每一个步骤都是对相应层次解决方案的抽象的逐步求精。

2****求精 Refinement

又叫做逐步求精指的是通过程序细节连续细化来开发程序体系的策略。

分步骤的对程序抽象进行分解直至成为编程语言的过程同时造就了程序的层次结构。在这一点上要对细节多做考虑，这也展示了求精实际上是个苦心经营的过程。

3模块化 Modularity

指的是软件可被分割为分别命名并可寻址的组件（也叫做模块），将模块综合起来又可以满足问题的需求的性质。

” 软件的模块化是允许智能化管理程序的唯一属性。 ” 换句话说，当您将一个复杂问题分解为一些小问题时会更容易解决。

需要重点解释的是即使一个系统必须象 ” 单片机 ” 一样来实现，它也可以采用模块化设计。

4****软件体系（架构） Software Architecture

涉及到程序的两个重要特性： 1) 模块的层次结构。 2)数据结构 。

这源自于需求分析时将真实世界问题的含蓄定义与软件解决方案的要素关联起来的分割过程。

当问题的每个部分通过一个或多个软件要素得到解决后，与问题的定义和解决相一致软件和数据结构的进化就开始了。

这个过程代表了软件的需求分析和设计之间的位置。

5****控制层级 Control Hierarchy

也称作程序结构，描述程序组件的组织并意味着控制层级。

它并不描述软件的程序方面，比如进程顺序、决定的事件 / 命令、或工作循环。

如下的层级图表展示了模块之间的通信流，并显示哪些模块是重复的（右上角变黑的块）。

这个图表描述了一个能够读文件，计算每个记录的值并书写报表来显示记录的信息和所完成的计算。

6****数据结构 Data structure

描述了单个数据间的逻辑关系。数据结构规定了数据的组织、访问方法、关联程度、和信息的选择处理。

数据结构的组织和复杂性只受限于设计者的灵活性。唯一的限制就是经典数据结构的数量阻碍了更多的久经考验的结构出现。

7****软件程序 Software Procedure

着重于处理每个模块的细节并必须提供一个精确的处理规范，包括事件顺序、准确的判定点、重复操作、甚至数据结构。

软件的程序表现是分层的，处理方法应该包括其所有子模块的参考。

8****信息隐藏 Information Hiding

的法则建议 由设计决定所刻划的模块特性应该对其余的模块不可见 。

换句话说，模块应被设计和指定为包含在模块内部且其他模块不可访问的内容对其他模块来说是无需的。

隐藏意味着有效的模块性能够通过定义一套独立的模块来实现，这些模块相互之间的通信仅仅包括实现软件功能的所必须的信息。

将使用信息隐藏作为设计标准在测试或今后的维护期间需要修改系统时带来了最大的好处。

五（软件）设计方法论*

让我们来遍历设计过程中用以促成模块化设计的四个区域： 模块 Modular 、数据 Data 、体系 Architectural来源：小熊coder