高级需求分析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调用

原文地址:https://www.cnblogs.com/hrhguanli/p/5074151.html