1、 大多数需求分析是在细化阶段进行的,并且伴以具有产品品质的早期编程和测试。P37
2、 需求(requirement)就是系统(更广义的说法是项目)必须提供的能力和必须遵从的条件。P40
3、 以本质风格编写用例:摒除用户界面并且关注参与者的意图。P61
4、 用例工作之重在于编写文本,而非图形或用例关系。P68
5、 准则:模型-视图分离原则。P154
该原则至少具有两部分:
1)不要将非UI对象直接与UI对象连接或耦合。例如,不要让Sale软件对象(非UI“领域对象”)引用Java Swing JFrame窗口对象。因为窗口与某个应用相关,而(理想情况下)非窗口对象可以在新应用中重用或附加到新界面。
2)不要在UI对象方法中加入应用逻辑(例如税金的计算)。UI对象应该只初始化UI元素、接受UI事件(例如鼠标点击按钮)、将应用逻辑的请求委派到非UI对象(例如领域对象)。
模型-视图分离的动机包括:
l 支持内聚的模型定义,这些定义只关注领域过程,而不是用户界面。
l 允许对模型和用户界面层分别进行开发。
l 是界面的需求变更对领域层的影响最小化。
l 允许新视图能够被方便地连接到现有的领域层之上,而不会对领域层产生影响。
l 允许对同一模型对象同时使用多个视图,例如销售信息同时具有表格和业务图表视图。
l 允许模型层的运行不依赖于用户界面层,例如,消息处理或批处理模式的系统。
l 允许简模型层能够简便地移植到另一用户接口框架下。
6、 应该花费时间使用交互图进行动态对象建模,而不仅是使用类图进行静态对象建模。P164
为什么?因为当我们要考虑真正的OO设计细节时,就必须要“落实”发送哪些消息、发送给谁、以何种顺序发送等具体问题。
7、 GRASP(General Responsibility Assigment Software Patterns —— 通用职责分配软件模式)的9个模式:
创建者(Creator)
信息专家(Information Expert)
低耦合(Low Coupling)
控制器(Controller)
高内聚(High Cohesion)
多态性(Polymorphism)
纯虚构(Pure Fabrication)
间接性(Indirection)
防止变异(Protected Variations)
8、 正常情况下,控制器应当把需要完成的工作委派给其他的对象。控制器只是协调或控制这些活动,本身并不完成大量工作。P221
9、 边界对象(boundary object)是接口的抽象,实体对象(entity object)是与应用无关的(一般是持久的)领域软件对象,控制对象(control object)是此控制器模式描述的用例处理者。P221
10、 模块化是将系统分解成一组内聚的、松散耦合的模块的特性。P229
11、 可见性(visibility)是对象“看到”或引用其他对象的能力。
实现对象A到对象B的可见性通常有四种方式:
·属性可见性 —— B是A的属性。
·参数可见性 —— B是A中方法的参数。
·局部可见性 —— B是A中方法的局部对象(不是参数)。
·全局可见性 —— B具有某种方式的全局可见性。
考虑可见性的动机是:为了使对象A能够向对象B发送消息,对于A而言,B必须是可见的。