谈谈软件开发那些事 笔记3

1,们分析和设计系统的基本原则是职责驱动设计，那么职责分配的原则是什么呢？信息专家模式回答了我们。信息专家模式（又称为专家模式）告诉我们，在OO分析中，应当将职责分配给软件系统中的这样一个对象类，它拥有实现这个职责所必须的信息。我们称这个对象类叫“信息专家”。
2,高内聚从本质上提高了软件的可读性、可复用性和可维护性，因此，高内聚已经成为软件设计中的一种基本品质。但是，高内聚从内在要求软件中的所有元素必须充分协作，从而必然造成元素之间的相互感知，也就是相互耦合。高内聚与低耦合成为了一对矛盾，就要求我们在设计过程中必须寻找那个最佳的中间点，既满足高内聚，又能很好的低耦合
3,敏捷开发的作者提倡用草图画图，跟客户交流的时候边花边修改。需求确定下来的时候是一张一张的草图而不是Rose中完整的图。敏捷开发的作者还提倡，需要的时候才花，不需要就不花，不要过度设计。如行动图、序列图和状态图，你需要表达更清楚的时候才画，不是为画图而画图，图只是你表达的一种工具。
4,需求规格说明书是面向过程时代的产物，因此它的核心就是按照面向过程的设计思想编写需求；用例模型是面向对象分析/设计的产物，因此它的核心思想就是OOA/D（面向对象分析/设计）
5,一些初学者认为，用例模型就是画张用例图。其实这是错误的，用例模型包括用例图、用例说明，有时还要辅之一些简单的行动图、状态图和序列图。用例图采用图形的方式，形象生动地展现了用例、参与者和系统边界之间的关系。而用例说明，是对用例、参与者和系统边界进行的详细描述。在描述过程中，还可以对一些关键的流程，以及这些流程中关键类的状态变化，使用行动图、状态图和序列图进行图形化地展现
6,如何发现用例,当我们开始一个项目的需求分析时，肯定是去听客户谈他们的需求，或者看客户提交的业务需求文档。这其中，客户一定会提出一个又一个的功能或要求，他们中的每一个就成为了我们最初的用例。分析这些用例，关注它们每一个的参与者，以及它们相互之间的关系，这就形成了最初的用例模型
7,我们采用用例分析的方式与客户沟通需求的时候，我们应当着重关注的是参与者及其目标，即每个功能的参与者是谁，完成这个功能的目标是什么，以及如何完成这个目标。这时的用例说明采用概述的方式，即只进行主成功场景（基本流程）的描述。此后，我们继续与客户沟通，一方面，继续细化以后的用例，各个用例的替代场景（分支流程）逐渐被整理出来，用例在一步步细化。同时，我们对一些需求的认识一开始可能存在着偏差，因此我们还不断在更正我们的用例描述。另一方面，一些新的功能被用户提出来，形成一些新的用例
8，领域模型不是数据模型，也不是软件对象模型。个创建领域模型的过程中非常容易犯的错误就是，将领域模型当成了数据模型，或者软件对象模型。领域模型，又称为概念模型、领域对象模型或分析对象模型，是“专用于解释业务领域中重要的‘事物’和产品”。领域模型专注于现实世界的对象（概念类）而非软件世界的对象。它不包含任何数据库元素、软件类、系统架构以及有职责的软件对象。日后的分析模型、设计模型以及数据模型，将以领域模型作为参考，但很可能与领域模型存在较大差异
9，过去C/S的年代，需求分析往往画的是数据模型。数据模型，也就是我们常说的E-R模型（实体-关系模型），它是基于关系数据库的一种分析模型，其间包含了大量的数据库元素，如主键、外键、数据依赖等等。领域模型不是数据模型，它不应当包含这些内容。
10，领域模型与软件对象模型同为类图，从而造成领域模型常常与这类模型产生混淆。领域模型是对现实世界的对象的反映，因此领域模型不应包含诸如工厂类、窗口界面、软件架构之类的软件元素，领域模型也不等同于之后用于设计开发的分析模型和设计模型。
11，领域模型中的概念类通常都只有相关的主要属性，没有任何的方法或函数（有时候概念类连属性都可以省略，仅仅描述它们之间的关系）。
12，领域模型不是一张图，而是一系列图形.领域模型应当划分成一个又一个的场景，每个场景一张图，进行领域分析.如果某个模块涉及的概念不多并且关系清晰，我们可以使用一个较大的场景进行描述；如果某个模块涉及的概念纷繁并且关系复杂，我们可以划分成一些更小的场景分别进行描述。领域模型划分的场景不论粗还是细，宗旨便是让读者阅读时清晰明了。
13,在软件项目的需求调研过程中，语言沟通一直是困扰我们的一大难题。业务人员在他们自己的领域中有一套他们自身的语言，运用这套语言，他们相互之间可以灵活自如地沟通；软件技术人员在我们的技术领域有我们的一套语言，运用这套语言，我们也可以轻松愉快地沟通。但是，当业务人员和技术人员坐在一起时，问题就出现了。业务人员和技术人员他们各自说各自的一套语言，各说各的话，相互沟通就存在了巨大地障碍。按照以往的经验，解决这个问题的办法就是，技术人员通过自身的努力去掌握业务语言，用业务语言去沟通；业务人员耐心地去解释业务术语给技术人员听，一步一步地去讲解业务领域的一个个流程。这样的过程是一个艰巨的过程。怎样让这样的过程更加高效呢？也许画几个图，用图形化的展示能更加生动形象，从而提高沟通的效率
14,同时，领域模型又是日后的技术人员进行分析设计的基础，因此领域模型所采用的语言必须让技术人员能看得懂。正因为领域模型所起到的重要作用——业务领域与技术实现的沟通介质，领域模型必须采用一种通用语言。同时，领域模型对一些关键的业务术语的解释，以及各个概念类相互关系的描述，也大大降低了沟通的难度。
15,OOA/D的核心思想就是，软件系统中的所有对象都是有各种职能的、高度内聚的对象，软件功能的实现就是这些对象根据各自的职能相互配合完成的。为了实现这样一个设计思想，低表示差异的概念被提出来了。什么是低表示差异呢？说得更加直白一点儿就是，软件中的对象及其职能，与现实世界中对应的事物及其职能，应保持尽量接近。低表示差异为降低软件设计难度，提高系统可读性，都带来了极大好处。毫无疑问，在需求分析阶段建立领域模型，大大提高了软件设计的低表示差异。
16,当需求分析结束、需求确认完成、需求讨论告一段落的时候，我们的需求分析员拿出了厚厚的一打用例分析模型、领域设计模型，需求分析阶段结束.
17,在需求分析阶段结束以后，许多公司（包括我们）通常的做法都是立即进入开发编程阶段。开发人员与需求人员坐在一起开了一个简短的动员会，按照模块和功能的划分，给所有的人进行一次任务分配，紧接着开发人员就领着自己的任务开始埋头开发。诚然，几乎所有的开发任务时间都是非常紧张的，但是没有经过规划和设计的系统，往往是无序和低效的。那些我在《谈谈软件开发的那些事儿》中提到的噩梦就是这样开始的。随意地创建对象，随意地分配属性和方法，随意地相互调用，都会大大降低软件的可维护性。一个小小的变更，就会让我们的软件大动筋骨，从何谈起拥抱变化呢？要提高软件的可维护性、可变更性，就必须让我们的设计低耦合、高内聚，也就必须做到职责驱动设计（RDD）。建立必要的分析模型和设计模型，可以帮助我们做到这一点
18,分析模型和设计模型就是在需求分析结束后、程序开发开始前的这段分析设计阶段使用的。按照RUP的流程，应当先建立分析模型，然后再建立设计模型。但是分析模型和设计模型没有明显的时间分隔，通常都是经过无数次迭代，从分析模型逐渐过渡到设计模型。分析模型是在不考虑任何技术实现的前提下进行的纯OO分析的模型。不论你的系统是采用J2EE实现还是C++实现，分析模型都是一样的。而设计模型则相反，设计模型开始考虑具体技术的实现。因此，从分析模型到设计模型是一个从抽象到逐渐细化的过程。
19,谁来完成从分析模型到设计模型的整个过程？我认为，应当是需求分析人员和架构分析师共同来完成。然而，在实际情况是，更多的工作是需求分析人员来完成的。因此，那些由技术出身的，拥有扎实OO分析设计基础的需求分析员在完成这些工作时会更加得心应手。下面我们看看分析模型是怎样开始分析和设计的
20,我们在开始分析模型的时候，首先要弄清楚一个非常重要的原则，就是以职责为中心。OO分析设计的核心原则之一，就是软件系统中的所有元素都必须具有高度相关的职责，也就是说，软件系统中所有的模块、包、对象类，都应当拥有一个清晰的职责，并且与它相关的所有元素（即模块中的所有包、包中的所有对象类、对象类中的所有属性和行为）都必须与这个职责具有高度的相关性
21,分析模型的首要设计原则就是职责驱动设计（Responsibility-Drive Design）。依据职责驱动设计的原则，我们在分析系统的时候，必须为每一个模块、包、对象类，特别是对象类，定义一个明确的职责。在这个原则下，我们最核心的问题是，我们在定义每一个对象类时都应当为其定义职责，在定义它的行为和属性时，都应当与其职责高度相关。
22,从严格意义上讲，领域模型还不算是真正的OO分析和设计。真正的OO分析和设计是在需求分析人员完成需求分析以后，由技术人员完成的分析和设计（即分析模型和设计模型）。但领域模型在为日后的分析与设计准备着素材。用例模型为日后的分析与设计准备着流程操作方面的素材（动态模型），而领域模型为日后的分析与设计准备着类与类之间关系方面的素材（静态模型）。领域模型就是描述日后可能关心所有事物.以及它们之间的关系。因此，领域模型是一批类图，以及它们的说明。它与用例模型在需求分析阶段一起进行编写，不分先后顺序，并在完成该阶段以后作为工作成果一起提交
24,从业务领域提取知识.提取概念类 ,建立关联关系 .领域模型的说明