BlogJava-心情小站-随笔分类-OOA/OODhttp://www.blogjava.net/RongHao/category/25324.html勤学、勤思zh-cnTue, 04 Sep 2007 17:27:38 GMTTue, 04 Sep 2007 17:27:38 GMT60UML精粹学习笔记（四）http://www.blogjava.net/RongHao/archive/2007/09/04/142703.htmlronghaoronghaoTue, 04 Sep 2007 09:38:00 GMThttp://www.blogjava.net/RongHao/archive/2007/09/04/142703.htmlhttp://www.blogjava.net/RongHao/comments/142703.htmlhttp://www.blogjava.net/RongHao/archive/2007/09/04/142703.html#Feedback0http://www.blogjava.net/RongHao/comments/commentRss/142703.htmlhttp://www.blogjava.net/RongHao/services/trackbacks/142703.html 最关键的软件开发工具是受过良好设计原则训练的思维，而不是UML或其他任何技术。

RDD是思考OO软件设计的一般性隐喻。把软件对象想象成具有某种职责的人，他要与其他人协作以完成工作。RDD使我们把OO设计看作是有职责对象进行协作的共同体。

分配职责的基本模式是GRASP。

创建者模式
  问题：谁创建类A的实例？
  建议：如果以下条件为真时（越多越好），将创建类A实例的职责分配给类B：
        1、B“包含”或组成聚集了A。
        2、B记录A。
        3、B紧密的使用A。
        4、B具有A的初始化数据。
        首选聚集或包含A的类B。
  注意：A和B指的都是软件对象而不是领域模型对象。
  禁忌：对象的创建常常具有相当的复杂性。在一些情况下，更适合使用工厂。

信息专家模式
  问题：给对象分配职责的基本原则是什么？
  建议：把职责分配给具有完成该职责所需信息的那个类。把职责和数据置于一处，把服务与其属性置于一处。
  禁忌：相比较而言系统关注更为重要，设计要分离主要的系统关注。例如：领域对象加入持久化逻辑成为充血模型，这就把应用逻辑与数据库逻辑混合起来了（不良设计）。

低耦合模式
  问题：如何减少因变化产生的影响？（高耦合并不是问题所在，问题是与某些方面不稳定的元素之间的高耦合）
  建议：分配职责以使（不必要的）耦合保持在较低的水平。（信息专家模式支持低耦合）

控制器模式
  问题：在UI层之上首先接受和协调系统操作的对象是什么？
  建议：把职责分配给能代表下列选择之一的对象：
        1、代表全部“系统”、“根对象”、运行软件的设备或主要的子系统（外观控制器的变体）。
        2、代表发送系统操作的用例场景（用例或会话控制器）。

高内聚模式
  问题：怎样使对象保持有内聚、可理解和可管理，同时具有支持低耦合的附加作用？
  建议：职责分配应保持高内聚。委派职责。内聚性低的类通常表示大粒度的抽象，或承担了本该委托给其他对象的职责。

多态模式
  问题：如何处理基于类型的选择？如何创建可插拔的软件构件？
  建议：当相关选择或行为随类型（类）有所不同时，使用多态为变化的行为类型分配职责。不要测试对象的类型，也不要使用条件逻辑来执行基于类型的不同选择。
  经验：如果有一个具有抽象超类C1的类层次结构，可以考虑对应于C1中的公共方法特征标记来定义接口I1，然后声明C1来实现接口I1。

纯虚构模式
  问题：当并不想违背高内聚和低耦合或其他目标，但基于专家模式的方案又不合适时，哪些对象应承担这一职责？
  建议：人为制造类，由该类来承担一组高内聚的职责。该类并不代表问题领域的概念-是虚构的事物。例如DAO
  纯虚构通常基于相关的功能性进行划分，因此这是一种以功能为中心的对象。

间接性模式
  问题：为了避免两个或多个事物之间的直接耦合，应该如何分配职责？
  建议：将职责分配给中介对象。例如，Adapter
  间接性的动机通常是为了低耦合，并且大多数间接性中介都是纯虚构的。

防止变异模式
  问题：如何设计对象、子系统和系统，使其内部的变化或不稳定性不会对其他元素产生不良影响？
  建议：创建稳定的接口。
  不要和陌生人讲话：约束了应该在方法里给哪些对象发送消息。它要求在方法里，只应给以下对象发送消息：
  1、this对象（自身）
  2、方法的参数
  3、this的属性
  4、作为this属性的集合中的元素
  5、在方法中创建的对象
  典型违反该原则的例子： F f=foo.getA().getB().getC().getD().getE().getF();

命令-查询分离原则：
  执行动作（更新、调整，等等）的命令方法，这种方法通常具有改变对象状态等副作用，并且是void的（没有返回值）。
  向调用者返回数据的查询，这种方法没有副作用，不会永久性地改变任何对象的状态。
关键在于：一个方法不应该同时属于以上两种类型。
 
在绘制交互图时考虑和决定职责分配。然后在类图的方法分栏里概括职责分配结果，方法是职责的具体实现。


ronghao 2007-09-04 17:38 发表评论
]]>UML精粹学习笔记（三）http://www.blogjava.net/RongHao/archive/2007/09/03/142404.htmlronghaoronghaoMon, 03 Sep 2007 09:50:00 GMThttp://www.blogjava.net/RongHao/archive/2007/09/03/142404.htmlhttp://www.blogjava.net/RongHao/comments/142404.htmlhttp://www.blogjava.net/RongHao/archive/2007/09/03/142404.html#Feedback1http://www.blogjava.net/RongHao/comments/commentRss/142404.htmlhttp://www.blogjava.net/RongHao/services/trackbacks/142404.html
在多个迭代里对同一用例进行增量式开发。

细化阶段：构建核心架构，解决高风险元素，定义大部分需求，以及预计总体进度和资源。（包括了三到四次的细化迭代）
关键思想和最佳实践：
 实行短时间定量、风险驱动的迭代
 及早开始编程
 对架构的核心和风险部分进行适应性设计、实现和测试
 尽早、频繁、实际的测试
 基于来自测试、用户、开发者的反馈进行调整
 通过一系列讨论会，详细编写大部分用例和其他需求，每个细化迭代进行一次
制品：领域模型、设计模型、软件架构文档、数据模型、用例、用户界面原型。

领域模型
领域模型是对领域内的概念类或现实世界中对象的可视化表示。
应用UML表示法，领域模型被描述为一组没有定义操作的类图，反映属性和关联。（一定注意，它不是软件对象！是概念对象！）
准则：
  使用领域术语
  认真汲取领域专家所使用的核心词汇和概念
  如果某概念类不是现实世界中的数字或文本，那么她可能是概念类而不是属性
  需要描述类：1、需要有关商品或服务的描述，独立于任何商品或服务的现有实例；2、减少冗余或重复信                 息
  避免加入大量关联，添加关联是为了突出对重要关系的大致理解，而非记录对象或数据的结构
  通过关联而不是属性来表示概念类之间的关系，领域模型中属性的类型应该是数据类型（基本类型）
  对数量和单位建模
每次迭代的领域建模不超过几个小时。

系统顺序图
系统顺序图（SSD）是为阐述与所讨论系统相关的输入和输出事件而快速、简单地创建的制品。是操作契约和对象设计的输入。
SSD展示了直接与系统交互的外部参与者、系统（作为黑盒）以及由参与者发起的系统事件。这些事件是通过用例文本总结出来的。
应为每一个用例的主成功场景，以及频繁发生的或者复杂的替代场景绘制SSD。
基本上软件系统要对三种事件进行响应：来自于参与者的外部事件，时间事件，错误和异常（通常源于外部）。
系统事件应该在意图的抽象级别而非物理的输入设备级别来表达。

操作契约
操作契约使用前置和后置条件的形式，描述领域模型里对象的详细变化。其中的关键元素是后置条件。
为系统操作定义操作契约。系统操作在绘制SSD草图时确定。
后置条件描述了领域模型内对象状态的变化。可分为三种类型：创建或删除实例，属性值的变化，形成和消除关联。注意，它描述的是所需的变化，而不是这些变化是如何完成的。以说明性的、被动式的过去时态编写后置条件。（例如，创建了xx，而不是创建xx）

逻辑架构和UML包图
逻辑架构是软件类的宏观组织结构，它将软件类组织为包（或命名空间）、子系统和层等。
UML包图常用于描述系统的逻辑架构--层、子系统、包等。
将系统的大型逻辑结构组织为独立的、职责相关的离散层，具有清晰、内聚的关注分离。
协作和耦合是从较高层到较低层进行的，要避免从较低层到较高层的耦合。较低层包含可复用功能。
可以将应用逻辑层更准确地称为架构的领域层，即包含领域对象（注意领域模型与领域对象是不同的两个概念），处理应用逻辑的层。
领域层是软件的一部分，领域模型是概念角度分析的一部分。
从UI层发送到领域层的消息将是SSD中所描述的消息。

轻量级绘图然后编码。


ronghao 2007-09-03 17:50 发表评论
]]>UML精粹学习笔记（二）http://www.blogjava.net/RongHao/archive/2007/08/30/141475.htmlronghaoronghaoThu, 30 Aug 2007 09:59:00 GMThttp://www.blogjava.net/RongHao/archive/2007/08/30/141475.htmlhttp://www.blogjava.net/RongHao/comments/141475.htmlhttp://www.blogjava.net/RongHao/archive/2007/08/30/141475.html#Feedback0http://www.blogjava.net/RongHao/comments/commentRss/141475.htmlhttp://www.blogjava.net/RongHao/services/trackbacks/141475.html
在面向对象分析中（OOA），强调的是在问题领域内发现和描述对象。OOA关注从对象的角度创建领域描述，OOA的结果可以表示为领域模型。需要注意的是，领域模型并不是对软件对象的描述（区别于软件中的对象类），它是真实世界领域中的概念和想象可视化。

在面向对象设计（OOD）中，强调的是定义软件对象及它们如何协作以实现需求。（类图与顺序图）

迭代开发是OOA/D成为最佳实践的核心。建议迭代的时间在2-6周之间，小步骤、快速反馈和调整。迭代的一个关键思想是时间定量，或时长固定。
1、在第一次迭代之前，召开第一个时间定量的需求工作会议（两天）。业务和开发人员需要出席。
   a、高阶需求分析。仅仅确定用例和特性的名称，以及关键的非功能性需求（性能，可伸缩性等等）。
   b、通过架构师和业务人员，从高阶列表选择10%列表项（例如，30个用例名中的10%，3个）。这3个用例      需要具备：具有重要的架构意义；具有高业务价值；具有高风险（例如，可处理500个并发交易）。标      识这3个用例：UC2，UC11和UC14。
   c、剩下的一天半对这3个用例的功能和非功能性需求进行详细的分析。
2、在第一次迭代之前，召开迭代计划会议，选择UC2，UC11和UC14的子集，在特定的时间内（例如，四周）    进行设计、构造和测试。要注意，并不是在第一次迭代中就要构造全部的3个用例，可以将其分解为一系   列更为详细的迭代任务。
3、在三到四周内完成第一次迭代（严格遵守时间）
   a、在开始的两天内，开发者在架构师指导下分组进行建模和设计工作。白板，UML草图，界面、讨论。
   b、编程。注意UML草图只是参考
   c、测试
   d、结束前一周，检查是否能够完成初始迭代目标，如果不能，缩小迭代范围。
   e、最后一周的周二，冻结代码，集成和测试所有代码，建立迭代的基线。
   f、周三上午，演示此局部系统，展示早期可视进展，要求反馈。
4、在第一次迭代即将结束时（最后一周的周三周四），召开第二次需求会议，对上次会议的所有资料进行复   查和精化。然后选择具有重要架构意义和高业务价值的另外10%到15%的用例，一到两天详细分析。这项工   作完成后，大约20-25%的用例得到了详细记录。
5、周五上午，举行下一迭代的迭代计划会议。
6、相同步骤2次迭代。
7、反复四次迭代和五次需求会议，这样在第四次迭代结束后，可能已经详细记录了80-90%的需求，但系统只   实现了10%。
8、大概推进了整个项目过程的20%。up里，属于细化阶段。此时，可以估计整个项目的工作量和时间。
9、一般不再需要需求会议，需求已经稳定了。接下来是一系列为期三周的迭代，在最后一个周五召开的迭代   计划会上选择适宜的下一步工作。
  
早期的迭代要致力于核心架构的构造，应该首先处理困难的和具有风险的事物。

建模（构建UML草图）的主要目的是为了理解，而非文档。只需对设计中不常见、困难和棘手的一小部分问题建模和应用UML。不要单独建模，而是结对（或三个人）在白板上建模。并行的创建模型（例如，类图和顺序图交替开始）。UML细节是否精准不重要，重要的是人员能够互相理解。坚持用最简单、常用的UML元素。开发者应该为自己进行OO设计建模，而不是创建模型图后交给其他人实现。

UP的核心思想是：短时间定量迭代、进化和可适应性开发。

初始阶段是建立项目共同设想和基本范围的比较简短的起始步骤。包括确定大部分用例名称，对10%的用例进行分析，关键的非功能需求的分析，业务案例创建和开发环境的准备。包含第一次需求研讨会，并为第一次迭代制定计划。要解决的主要问题：涉众是否就项目设想基本达成一致，项目是否值得继续进行认真研究。

用例是文本形式的情节描述，特别注意，用例是文本不是图形！用例建模主要是编写文本的活动，而非制图。用例名称应使用动词开头。
参与者的三种类型：主要参与者，协助参与者，幕后参与者。
用例的三种常用形式：摘要，非正式，详述（在第一次需求会中，详细的编写其中少量（例如10%）的具有重要架构意义和高价值的用例）。用例应该包含所有涉众关注点的事物。
准则：
以无用户界面的本质风格编写用例；排除用户界面而关注参与者的意图。
编写简洁的用例。
编写黑盒用例，不对系统内部工作、构件或设计进行描述。而是通过职责来描述系统。
采用参与者和参与者目标的视点。


ronghao 2007-08-30 17:59 发表评论
]]>UML精粹学习笔记（一）http://www.blogjava.net/RongHao/archive/2007/08/27/140159.htmlronghaoronghaoMon, 27 Aug 2007 14:27:00 GMThttp://www.blogjava.net/RongHao/archive/2007/08/27/140159.htmlhttp://www.blogjava.net/RongHao/comments/140159.htmlhttp://www.blogjava.net/RongHao/archive/2007/08/27/140159.html#Feedback6http://www.blogjava.net/RongHao/comments/commentRss/140159.htmlhttp://www.blogjava.net/RongHao/services/trackbacks/140159.html倾向于将UML用于草图绘制，绘制草图的实质是选择，重点是进行交流，常用的介质是白板。
草图是故意不完备的，要突出重要的信息。草图是探究性的，蓝图是定义性的。草图用于正向工程（设计阶段），蓝图用于逆向工程（根据已有的代码导出）。详细文档应该根据代码生成。

UML最重要的是类图和顺序图。

瀑布风格和迭代风格
瀑布风格是基于活动来分解项目的，迭代风格根据功能子集来分解项目。
迭代的一种常用技术是时间框定法，迫使各次迭代的时间长度固定。通过定时搁置功能，使人们能够在搁置日期和搁置功能之间进行明智的选择。

敏捷过程是强适应性的过程。敏捷方法强调项目成功最重要的因素是人的素质以及人之间的良好协同，敏捷方法倾向使用时间框定的短小迭代。每一次迭代结束时要进行一次迭代回顾。

RUP本质上是一个迭代过程，分为四个阶段：初始，细化，构造，移交。
需求分析最重要的是与用户及客户的交流。

类图
类图表述系统中各个对象的类型以及其间存在的各种静态关系。
对不重要的事（如日期或布尔值，一般说，值类型）使用属性，对较为重要的类使用关联。
非常反感那些除了一组域及其get/set方法没有行为的类。如果你在利用get方法重复调用数据，这预示着某一行为应该移往具有数据的对象。
依赖应该单向，依赖越少越好，特别谨慎循环依赖，尤其反对包间的循环依赖。对类使用依赖最常见的情形是阐明瞬间关系，比如，把一个对象作为参数传递到另一个对象时。
不要试图使用对你可用的所有图示法，保持图示简单，集中考虑关键方面。绘制类图时总以使用某种形式的行为技术为宜。

顺序图
尽量省去回送。
单一职责，提倡分布式控制（把处理分散到多个对象里去）。
减少过程式编程，如if/else，改用多态解决类似问题。
把顺序图看作各个对象如何交互的形象化表示而不是一种对控制基理的建模方法。顺序图擅长示明对象间的协作，不擅长于示明行为的精确定义。

CRC卡
CRC的一个重要部分是认识职责。任意一个类都可以用少量职责对其概括。对具有三项以上职责的卡片提出质问，是否应该把类分解，或把职责合并成一个更高层次
的概述。


ronghao 2007-08-27 22:27 发表评论
]]>