高级需求分析UML建模设计模式笔记

1.REQ->HLR 分析 全系统性质->AD设计 Context,BOM,Conception
2.REQ->LLR 分析   模块分析->DD设计 + 编码 Feature,BRM,UC,UCD
3.DD设计->代码结构设计 模块内 30个功能 ->类/序列图设计,反射/继承/接口/设计模式/实体类/抽象/配置文件

代码结构设计: 

设计目标：正确性目标-> 

功能性需求目标:代码结构能够实现所有业务要求

非功能性需求目标：
复用性:避免代码冗余
可扩展性:满足所有 业务功能 <->Feature 可变性要求
安全性:加密,身份认证,验证,授权,XSS
性能:秒钟计算,内存缓存
代码稳定性:代码结构设计后代码平均每个月的重构次数;

分类->封装类
依据业务+单一职责
30Featrue ->30类
Featrue->类/公有方法/私有方法 不需要依据业务设计
领域模型：实体数据

UC->KPC 关键功能点->公有方法

接口设计/基类的设计/抽象类/复用设计/继承/委让

1.接口设计原则:
a.用于模块功能暴露,多用于模块间
b.接口定义纯虚,所有实现必须有个性实现
c.接口传入参数与传出参数尽量避免使用基本数据类型
d.接口传参应尽量使用领域模型[实体数据]
e.接口名称应尽量使用业务名称
f.接口定义应由自身模块定义,不能由调用方决定,自治
FindData(ID)
FindData(ID,Date) 如果添加请调用方自己添加日期解析
g.接口最小化/接口单一,通过组合复用进行接口复合调用

2.基础类与继承的设计:
Class:基础类的最常用形式,无法强制子类个性化实现
Abstract Class: Class继承代码复用,定义纯虚
Interface : 无法代码复用,继承树,完整被暴露到外部

继承与委让/复用设计:代码复用
使用委让进行代码复用


可扩展性设计：
1.分析Featrue可变性,共性
2.设计BaseClass,共性定义在基类中,可变性通过纯虚定义在子类里,设计出继承体系/继承树
3.所有调用方,调用基类,不能直接调用子类
4.通过多态,由基类调用到子类
5.定义Factory,完成多态过程
6.多态业务逻辑定义在xml文件


依赖倒置原则:
调用方应该调用抽象或者基类,而不是调用子类

里氏替换原则:
检验可扩展性的继承树是不是有效


类的划分:
信息专家：业务逻辑类Service
数据实体：保存数据 Entity结尾
创建者：可扩展性设计  Factory
管理者：管理模块内的所有的类,Manager/缓存数据实体)
边界类：接口实现Imp
界面类: View
控制器: Control


详细设计的实践原则:
1.分析Featrue,BRM(活动图)
2.分析细节需求
3.依据设计核心原则[依据封装+单一职责原则,从Featrue->类的划分]
4.分析细节需求->方法的定义
5.分析BRM->类间关系定义
6.依据GRASP设计原则,将类划分成7大类别
7.分析Feature可变性,逐一分析
8.根据Feature可变,分析共性与特性,共性形成继承基类,特性形成了子类,完成继承树设计,依据开闭原则
9.修改调用方调用基类,依据的是依赖倒置原则
10.定义Factory+xml 实现扩展设计
11.依据里氏替换原则,验证继承树调用过程中是否存在风险
12.复用性设计
13.逐一分析Featrue,需要对外提供访问,设计为接口 依据[接口设计实践原则,接口最小原则]
14.通过设计模式改良设计
15.完成类图设计
16.完成序列图(时序图)设计
17.进行团队间详细设计评审
18.形成详细设计文档
19.未来应不断监控设计的变更,由需求导致设计的重构[采用72种重构方法,进行可扩展性重构]

规范
创建性设计模式:
抽象工厂模式:不直接New来生成类的实例
原型模式：
Builder模式:
Singleton单例模式:

结构性模式
面板模式:复杂过程的封装   可以跨类调用
适配器模式:对于外部组织封装  不可以跨类调用
装饰器模式:就是根据配置文件进行for调用不同的清洗方法
代理模式:典型的webserver调用

原文：http://blog.csdn.net/xiaohuaidan1988/article/details/40078833