课程费用

5800.00 /人

课程时长

2

成为教练

课程简介

一个背景:软件产品化
一个中心:可扩展设计
一套实践:拉通需求、设计和代码,让“需求的变更”变成“代码的扩充”

目标收益

一个背景:软件产品化
一个中心:可扩展设计
一套实践:拉通需求、设计和代码,让“需求的变更”变成“代码的扩充”

培训对象

1.想听架构课程的所有学员,包括架构师、技术经理、开发高手、开发骨干
2.想从重复做项目,过渡到做产品的团队

课程大纲

Big Picture——产品化:误区与真相 产品化,就是死磕“可扩展”
 可扩展的实质:需求有变更,代码可方便扩充
 远离代码不行:代码可扩充?架构设计是条件,详细设计是关键

成功的两个条件和两个关键
 【条件一】将产品扩展压力,捕捉为需求
 【条件二】架构要稳定,即代码扩充时架构不变
 【关键一】模块间接口是隔离模块、使模块可扩展的关键
 【关键二】模块实现是否重用与可变分离,是第二个关键
【需求篇】 产品扩展压力,如何尽早捕捉为需求?

设计产品化软件,洞察需求变更的几点规律
1. 什么需求没变?
2. 什么需求在变?
3. 分析和识别需求变更的实际技巧


设计产品化软件,可这么加强需求文档
1. 分析: 《SRS》案例一 vs. 《SRS》案例二
2. 练习:学员将需求的变更,定义到这两份文档中
主要收获:体会《SRS》的变更包容力不同
主要收获:长期以来“输入-处理-输出”式需求的弊病
主要收获:专业的话,用例技术这么用

分析、识别需求变更实战
1. 小组任务:应用上述技巧,分析和识别功能变更
2. 小组提交:xxx组《用例图 + 用例规约》
3. 小组对标:老师提供的《用例图 + 用例规约》
【架构篇】 为支持扩展,产品化的架构必须稳定!
设计师划分模块时,代码结构的全局划分方法
1. 从模式开始——巧妙的“五横一纵”分层模式
2. 模块划分——覆盖上下文图定义的接口需求
3. 模块划分——覆盖功能树、用例定义的功能需求
3.1. 起步:分析用例规约,识别实现用例需要哪些类
3.2. 后续:协作设计,即用序列图、协作图串起这些类
3.3. ……即运用用例驱动设计思维

专项练习
1. 用例驱动
2. 到底是“用例模块类”还是“用例类模块”

设计师划分模块时,注意几个基本原则
1. 通用-专用分离:提炼应用无关的Library、或选择三方库
2. 通用-专用分离:机制与策略分离,开发或选择Framework
3. 隔离外部交互:仅UI层“知道”操作细节和展现格式
4. 隔离外部交互:仅SI层“知道”和外部系统通信的细节
5. 隔离外部交互:仅DM层“知道”数据存储格式

设计师划分模块时,可参考的优秀范例一则
1. 著名开源产品套件——Mumble
主要收获:模块的划分、通用库的提炼、三方框架…

实战演练
1. 任务:模块划分,必须覆盖代码结构全局、不能漏模块
2. 贯穿案例推进……
【详细设计上】 承载产品功能的代码模块,重用与可变分离!
设计师设计模块时,利用好OO Package结构规律
1. 提供中心控制类,不要暴漏一堆小类
2. 接口类与实现类分离
3. 通用实现类与扩展实现类分离
4. ……


如何应用上述结构,包容需求变更
1. 分析需求变更,扩充/增加/改变 用例规约
2. 分析对设计的影响
a) 增加了Optional Feature (最常见)
b) 改变了Function Point
c) 改变了Process Flow
3. 如何设计合理的OO Package支持上门三种变更

设计师设计模块时,可参考的优秀范例二则
1. 一个通用库——类的组织
主要收获:接口分离、提供中心控制类、可扩展支持
2. 著名开源产品——类的组织
主要收获:抽象领域概念的提炼、可扩展支持

过关演练
1. 分析材料,熟悉设计要求
2. 设计一个通用模块,必须可扩展……
【详细设计下】 设计松耦合、可扩展的模块接口 设计师设计接口时,考虑的三件事儿
1. 技术选择:接口设计容易?做漂亮最难!
2. 机制选择:调用/回调/同步/异步/轮询/超时
3. 格式定义:函数风格 vs.报文或消息风格

设计师设计接口时,可参考的优秀范例几则
1. 某通用产品——漂亮的封装、方便的配置
主要收获:围绕Domain Type定义模块的核心接口
主要收获:在核心接口基础上,可定义便捷接口
注英文术语为Core Interface、Convenience Interface
2. 某平台接口分析——既能跨平台又方便调用?
主要收获:跨平台协议 + 便于二次开发的API
1. MFC、Swing等API设计对比——更灵活的接口风格
主要收获:Message在接口设计中的作用
主要收获:Callback回调、及“注册-回调”接口机制

设计师设计接口时,这些经验可以用
1. 基于代码:专项练习一
2. 基于代码:专项练习二
3. 基于代码:专项练习三
4. 原则与“坑”总结

实战演练
1. 任务1:接口的命令化(Command)支持可扩展
2. 任务2:让接口包含回调(Callback)使模块通用化
3. 贯穿案例设计推进……
Big Picture——产品化:误区与真相
产品化,就是死磕“可扩展”
 可扩展的实质:需求有变更,代码可方便扩充
 远离代码不行:代码可扩充?架构设计是条件,详细设计是关键

成功的两个条件和两个关键
 【条件一】将产品扩展压力,捕捉为需求
 【条件二】架构要稳定,即代码扩充时架构不变
 【关键一】模块间接口是隔离模块、使模块可扩展的关键
 【关键二】模块实现是否重用与可变分离,是第二个关键
【需求篇】 产品扩展压力,如何尽早捕捉为需求?


设计产品化软件,洞察需求变更的几点规律
1. 什么需求没变?
2. 什么需求在变?
3. 分析和识别需求变更的实际技巧


设计产品化软件,可这么加强需求文档
1. 分析: 《SRS》案例一 vs. 《SRS》案例二
2. 练习:学员将需求的变更,定义到这两份文档中
主要收获:体会《SRS》的变更包容力不同
主要收获:长期以来“输入-处理-输出”式需求的弊病
主要收获:专业的话,用例技术这么用

分析、识别需求变更实战
1. 小组任务:应用上述技巧,分析和识别功能变更
2. 小组提交:xxx组《用例图 + 用例规约》
3. 小组对标:老师提供的《用例图 + 用例规约》
【架构篇】 为支持扩展,产品化的架构必须稳定!

设计师划分模块时,代码结构的全局划分方法
1. 从模式开始——巧妙的“五横一纵”分层模式
2. 模块划分——覆盖上下文图定义的接口需求
3. 模块划分——覆盖功能树、用例定义的功能需求
3.1. 起步:分析用例规约,识别实现用例需要哪些类
3.2. 后续:协作设计,即用序列图、协作图串起这些类
3.3. ……即运用用例驱动设计思维

专项练习
1. 用例驱动
2. 到底是“用例模块类”还是“用例类模块”

设计师划分模块时,注意几个基本原则
1. 通用-专用分离:提炼应用无关的Library、或选择三方库
2. 通用-专用分离:机制与策略分离,开发或选择Framework
3. 隔离外部交互:仅UI层“知道”操作细节和展现格式
4. 隔离外部交互:仅SI层“知道”和外部系统通信的细节
5. 隔离外部交互:仅DM层“知道”数据存储格式

设计师划分模块时,可参考的优秀范例一则
1. 著名开源产品套件——Mumble
主要收获:模块的划分、通用库的提炼、三方框架…

实战演练
1. 任务:模块划分,必须覆盖代码结构全局、不能漏模块
2. 贯穿案例推进……
【详细设计上】 承载产品功能的代码模块,重用与可变分离!

设计师设计模块时,利用好OO Package结构规律
1. 提供中心控制类,不要暴漏一堆小类
2. 接口类与实现类分离
3. 通用实现类与扩展实现类分离
4. ……


如何应用上述结构,包容需求变更
1. 分析需求变更,扩充/增加/改变 用例规约
2. 分析对设计的影响
a) 增加了Optional Feature (最常见)
b) 改变了Function Point
c) 改变了Process Flow
3. 如何设计合理的OO Package支持上门三种变更

设计师设计模块时,可参考的优秀范例二则
1. 一个通用库——类的组织
主要收获:接口分离、提供中心控制类、可扩展支持
2. 著名开源产品——类的组织
主要收获:抽象领域概念的提炼、可扩展支持

过关演练
1. 分析材料,熟悉设计要求
2. 设计一个通用模块,必须可扩展……
【详细设计下】 设计松耦合、可扩展的模块接口
设计师设计接口时,考虑的三件事儿
1. 技术选择:接口设计容易?做漂亮最难!
2. 机制选择:调用/回调/同步/异步/轮询/超时
3. 格式定义:函数风格 vs.报文或消息风格

设计师设计接口时,可参考的优秀范例几则
1. 某通用产品——漂亮的封装、方便的配置
主要收获:围绕Domain Type定义模块的核心接口
主要收获:在核心接口基础上,可定义便捷接口
注英文术语为Core Interface、Convenience Interface
2. 某平台接口分析——既能跨平台又方便调用?
主要收获:跨平台协议 + 便于二次开发的API
1. MFC、Swing等API设计对比——更灵活的接口风格
主要收获:Message在接口设计中的作用
主要收获:Callback回调、及“注册-回调”接口机制

设计师设计接口时,这些经验可以用
1. 基于代码:专项练习一
2. 基于代码:专项练习二
3. 基于代码:专项练习三
4. 原则与“坑”总结

实战演练
1. 任务1:接口的命令化(Command)支持可扩展
2. 任务2:让接口包含回调(Callback)使模块通用化
3. 贯穿案例设计推进……

活动详情

提交需求