《UML和模式应用》读书笔记

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、  GRASPGeneral 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的可见性通常有四种方式:

·属性可见性 —— BA的属性。

·参数可见性 —— BA中方法的参数。

·局部可见性 —— BA中方法的局部对象(不是参数)。

·全局可见性 —— B具有某种方式的全局可见性。

考虑可见性的动机是:为了使对象A能够向对象B发送消息,对于A而言,B必须是可见的。

你可能感兴趣的:(工作,UI,object,swing,读书,UML)