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
