详细设计3天学习笔记

2011.10.13软件详细设计

组件之上为架构设计，之下为详细设计；

组建设计可以采用类图和序列图来表达出来，序列图是类方法之间的相互调用；

主要学习的详细设计，画出组建的类图和序列图；

设计有2个层次：

1、 软件有多少个模块（底层框架已经设计好）；

2、 模块之下是组件（组件形态为.dll文件，组件包，而且这样划分出组件之后，有利于工作任务的分配，最终形成编码）。

什么是架构：

系统分为多个组件，组件之间的调用关系由底层框架来完成。组件之间通用的功能也在架构中实现。

架构的静态划分：分层，子系统划分（分工协作）

架构的动态划分：公有的部分（持续一致的问题）

就像火车工程师一样，每节车厢之间是解耦的，而且是可配置的（车厢可以分开也可重新组合）；

详细设计：

对概要设计而言，是对组件功能细节的描述，算法、接口、数据结构、交互设计等；

通过类图和序列图来体现；

为什么要坐详细设计：

1.         需求和设计不断构建和改进；

2.         验证需求

开发人员：需求-详细设计-代码（开发人员在底层框架架构好之后就能做所有的事情）

项目管理流程

需求-需求列表-（架构设计）-设计-【界面原型-客户用例-详细设计-详细设计的内部评审（提出设计中出现的问题）-代码-测试-测试报告】

软件系统实现：可扩展性、可维护性、解耦、可插入性、可配置性

软件质量的特征：

1、 合适性

A、 功能性需求：业务需求是否满足；

B、 非功能性需求：性能，系统是否稳定、可靠和健壮性。

2、 结构稳定性

做需求时，判断出哪些是稳定不变的，哪些是可能变动的，根据可变的需求满足软件的”可扩展性”，“可扩展性“可以用继承和多态来实现，同时辅以配置文件。

3、 可维护性（软件频繁修改的情况下，软件依然很好维护）

1、 编码的可维护性（FXCOPE检测代码的规范性）；

2、 结构的可维护性：可扩展性、灵活性、可插入性，很容易将一个类抽出去，同时将一个有同样接口的类加进来。

A、 通过配置文件来完成（在XML中配置调用方法）

将逻辑记录在配置文件中，尽量能够通过配置文件完成系统业务的整合和添加。

B、 继承与多态来完成

通过对不同逻辑的继承实现，从而达到逻辑的扩展，进而采用多态的形式完成对扩展子类的调用（上溯造型）

3、 可复用性的完成

A、 实现组件化的开发（分化成不同的组件，生成dll文件）

B、 实现系统解耦（DI依赖注入对组件解耦）

 

 

面向对象的设计原则：

1、 封装（让类变位intrnal,组件内使用的类）

A、 组件封装 对外需要暴露的为public

B、 根据业务进行封装

组件化封装的特性：（面向对象最重要的技术）

A、 使用组件级的封装，当然类级也是需要封装的，偏向于组件的封装

B、 在组件化的过程中，以业务的相关性或相似性进行组件的封装，按照需求来封装，按照需求的不同层次来封装。

决定暴露哪些方法，哪些接口，一定由需求决定，功能决定，不能由调用方决定。

Public

Private 内部可见

Protected 继承可见

Internal

2、 继承 （类级别的）

继承的传统方式：特化和复用

新的：族化

A、 分类：相似业务场景进行分类

B、 扩展：子类具有不同的实现，达到扩展业务的能力、新功能

3、 抽象

4、 多态(使用同一个指令获得不同子类)

 

详细设计与UML

一个界面上会包含很多的组件

设计的步骤：

1、 了解需求

2、 对需求进行拆分-拆分成模块

3、 对模块进行拆分-拆分成组件

4、 确定系统的主界面风格

5、 详细设计

6、 编码

7、 测试

 

 

2011.10.14

1、序列图

2、grasp模式（通过职责分配软件模式）

         介于分析和设计之间，

         类在协作中承担的职责1、Knowing掌管信息2、Doing控制、协调类行为

组件内类设计的基本步骤：

1、 信息专家：组件内的业务逻辑分配在不同的信息专家类上，组件类，类去负责具体的业务逻辑，包含了具体的功能，信息专家最重要的是行为和方法，还有属性（有时也是业务实体），强调的是逻辑，即方法。

信息专家的不足：属性越多，则越冗余。

2、 数据实体

保存数据，从信息专家完成业务逻辑处理后，所形成的数据，交由数据实体保存和传递

3、 创建者

创建其他的对象，信息专家，数据实体factory

4、 控制者

管理组件内的所有对象 manager

5、 边界类

负责与外部的组件进行交互

 

 

低耦合模式（组件化开发）

耦合度：类与类之间的关联

低耦             高聚

间接调用         直接调用

组件间的低耦合   组件内的高内聚

 

多态模式（可扩展性，管理父类）

 

纯虚构模式

父类定义了子类的所有方法，调父类从而调用子类的所有方法

 

间接模式

组件通过底层框架相互调用，一般采用DI（依赖反转的形式）

 

保护变量模式

不要把变量随意的暴露

 

解耦（重要的前提是组件化）（解决的是业务改变以后的创面太大的问题）

1、 接口（一个功能因为调用方多，参数不同，而导致接口多）

2、 DI 调用底层框架来解耦

 

设计模式在详细设计中的应用

设计模式很难生搬硬套，一般是在设计完成后，看最终使用了哪些模式，对设计进行一下重构提高。

架构模式：

1、 DI解耦

2、 MVC 所有的BS结构运行程序中业务分离

目标：提升设计能力

设计思想的重用形成了设计模式

Pattern（模式）是沟通标准

1、 光用语言和UML还不够

2、 Pattern弹性及稳定

3、 解决问题的方法

模式有1、架构模式（MVC）

       2、平台模式（XML、SOAP、J2EE、。Net）

       3、设计模式（GOF23 面对DD（详细设计），Gang Of Four）

设计模式的分类

1、 创建型设计模式（创建者，帮助我们创造类）

2、 行为型设计模式（定义类之间相互交互的方式）

3、 结构型设计模式（如何组成）

 

创建型设计模式

Factory create –new

原型模式：prototype 现有的实例创造很多的对象 entity.clone()

 

Builder

 

Singleton

 

抽象工厂模式

 

结构型设计模式

1、 adapter 隔离调用方和被调用方，这样可以隔离我们的代码对外部不稳定的依赖。

2、 bridge 隔离抽象和实现

3、 composite组合模式（成员变量的使用）

两个类相同，B具有A的功能1、B继承于A     2、委让（委托）

4、 decorator装饰模式 （和Adapter很像）

对被调用方进行装饰和转换

5、 façade 外观模式

6、 享元模式 flyweight

组合复杂结构，把很多小对象结合成一个大对象

7、 代理模式Proxy

 

行为型设计模式

1、 责任链 chains of responsibility

类逻辑进行顺序性调用

2、 command命令模式

屏蔽后端复杂的业务实现，MVC是以Command模式来完成的

3、 解释器/拦截器 interpreter

存在大量数据的转化

4、 迭代器

5、 中介者

6、 备忘录

数据缓存，new对象时是缓存

7、 observer

8、 state

session

9、 策略模式

复杂的业务拆分成很多不同部分（if else or switch）

10、              模板方法

11、              Visitor 访问者

 

命令模式command

封装目标对象的行为，标准的为MVC模式，通过配置XML去执行后台的action。

日志、缓存、记录历史操作等，把一个操作写成一个command,当一个事务失败时，借助comman回退。

Thread pool线程池

 

2011/10/15

三层架构设计

1、 业务逻辑层

在业务组件层之下，将DB中的数据提取出来，SQl语句放在业务逻辑层有弊端，业务实体是在实际中存在的对象，业务逻辑层访问实体层时，有实体层提供数据

2、PDL持续数据层

A、 隔离数据源与应用程序

B、 实体数据层能够提供对数据的添加删除和修改

C、 将数据库的面向关系数据映射为面向对象设计

D、 提供对数据的缓存能力

E、 提供数据缓冲池

3、数据实体层的作用

A、 业务层和表现层之间传递数据

B、 数据不再依赖于数据源

C、 提供更大的可伸缩性

Custom business entities（面向业务）

自己写，性能提高，直接通过实体对象访问数据，代码不容易出错，business entities不直接访问数据库，business entities不初始化任何事务交易，应该将business entities设计为序列化，一般都有通用的基类、公用的接口，封装性强。

 

持久数据层代码展示

转载于:https://www.cnblogs.com/yaojian/archive/2011/10/17/2215276.html