[Arch] 03. Practice UML in project
学前复习
- 搜索：跟我学UML建模工具StarUML 系列文章
第一部分，下载和安装及破解StarUML工具软件
第二部分，StarUML工具软件的主要功能界面和UML图的创建示例
结合starUML，在项目中如何灵活使用各种Diagram。
在Diagram内部设计时，方针是什么：SOLID原则
以及若干软件模式：
- 体系结构模式，比如MVC，高层次的架构设计，需要先确定。
- 分析模式，不懂～
- 过程模式，项目开始后的各个阶段，每个阶段理论上可以有对应的文档。
- 设计模式，一线码农对待具体问题时需掌握的各种代码设计技巧。
StarUML常用图表
一、概览
| UML Minimal | Model | Main | ||||||||
| UML Conventional | Use Case Model | Use Cases用例图 | Analysis Model | Analysis | Design Model | Classes | Implementtation Model | Components | Deployment Model | Deployment |
| 4+1 View Model | Scenarios | Scenarios用例图 | Logical View | Logical View类图 | Development View | Developmenet View类图、组件图 | Process View | Process View无完全对应 | Physical View | Physical View部署图 |
| Rational | Use Case View | Use Case View | Logical View | Logical View | Component View | Component View | Deployment View | Deployment View | ||
| Data Model | Data Model | Main |
方法有许多，选一个4+1即可。
二、4+1 View Model
Ref: 4+1VIEW 软件系统视角模型
特点介绍
用于同时表达软件系统架构之多种观点的模型。
从系统共同利益人的角度(包括end-user、开发者和项目管理者)，分成4个观点。
- DevelopmentView (开发观点):
从开发人员的角度来看软件的管理，也被称作implementation view。他使用了UML图中的Componentdiagram来表达组件，Package diagram则用来表达更大型的系统。
- LogicalView (逻辑观点):
关心的是系统提供给end-user的功能。可表达的UML图包含activitydiagram, class diagram, state diagram。
- Physicalview (实体观点):
系统工程师的观点，关心的是系统 拓朴，包含组件之间实体上怎麽连接。其也被称作deployment diagram。
包含的UML图有deploymentdiagram
- Processview (进程观点):
着重在动态方面，关注解释系统在执行中的动作和组件如何沟通，用以解决同步问题、发布问题、整合问题、效能问题等等。
可表的UML图为 activitydiagram
- Scenarios (使用情景):
使用某些用例来描述系统架构，被称为第5个视角，也被称作use caseview，通常被用作测试雏型阶段的初始动作，被用来验证架构设计正确性。
三、学习总结
Jeff 笔记：
项目初期，Scenarios的用例图，以及配合更详细的用例规约表格，需求分析。
之后，LogicalView的活动图、状态图 是需要文档的。
然后就是，DevelopmentView的组件图，如果涉及多线程则考虑Process View。
最后就是，Physicalview的部署图，包括数据库的设计。
以上便是最起码需要掌握的。
实践笔记：
Back-end设计
需求分析：用例图，用例规约
业务流程：活动图，状态图
部署架构：数据库
Front-end设计
功能设计：UI流程图
软件工程各阶段的开发文档
Ref: 软件工程各阶段的开发文档
一：开发文档1.0（需求分析阶段）
所需材料：与客户面对面交流，通过一些针对性的引导问题让客户描述目标产品的要求。比如：您遇到了什么样的业务需求？您想做出一个怎样的东西去解决这个问题？
在这个系统中，会有哪些人（用户角色）？您的业务流程是怎样的？每一种角色，分别用这个系统做什么？
生成文档：从采集到的需求资料中得出《开发文档1.0》，主要有三部分内容：
一：系统概述：系统设计初衷（遇到的问题、想系统怎么解决这个问题）
二：用户角色：有什么角色会使用这个系统
三：概要需求：系统的功能、每个角色会怎么使用这个系统
【系统概述＋基本用例图】
二：开发文档2.0+项目计划书（概要设计阶段）
所需材料：把《开发文档1.0》交予客户审核确认修改。然后同时再次沟通，获取整个系统的使用流程、各个角色的使用流程、整个系统的具体功能列表。
生成文档：《开发文档2.0》：在《开发文档1.0》基础上，补全、新增：
三：概要需求：补全系统使用流程图、各个角色的使用流程图
四：功能列表：得出系统功能列表、每个角色模块的功能列表
五：系统架构：采用什么架构来开发这个系统
《项目计划书》：根据《开发文档2.0》大概估计项目的开发成本（时间、资源），然后针对各个项目模块的功能作出相应报价
一：开发成本汇报：所需时间、人力物力
二：项目模块报价：各个功能模块的功能列表以及实现这个模块的报价
三：整体项目报价
【系统架构＋详细用例图＋业务流程图＋报价】
三：开发文档3.0（详细设计阶段）
所需材料：《开发文档2.0》与《项目计划书》交付客户审核、确认、沟通修改，获取客户进一步的要求。
生成文档：《开发文档3.0》：在《开发文档2.0》的基础上新增：
六：功能详细设计：对每个角色的的每个功能进行详细设计，主要包括：
1：功能描述
2：功能流程
3：界面Demo
4：数据规约
5：数据实体 ----> 开始思考”类“
【功能详细设计(伪UI) + 数据规约】
四：开发文档4.0（详细设计阶段）
所需材料：《开发文档3.0》交予客户审核确认，特别是对详细设计部分的功能描述、界面Demo等作出确认。
生成文档：《开发文档4.0》：在《开发文档3.0》基础上新增：
七：模块划分：对角色各个功能进行划分，成为系统的模块。
八：数据库设计：由详细设计部分涉及到的数据实体与数据规约，以及对角色功能划分后得到的系统模块，进行数据库设计（创建什么表？表中属性有哪些？）
【确定系统各个子模块＋数据库设计】 <---- 架构内部细节逐渐清晰
五：开发文档5.0（详细设计阶段）
所需材料：《开发文档4.0》
生成材料：根据《开发文档4.0》中的数据库设计，对 第六点：功能详细设计 做出补充完善：
6：设计数据库中的表
7：功能实现的架构（把功能流程用架构表示，如：交互的操作在 XX.jsp，请求传给 xxservlet、数据操作 xx数据表）
补充：软件工程各阶段的UML图
详细设计阶段的类图。
详细设计阶段的时序图。
【进一步补充、完善】
六：根据《开发文档5.0》进行编码开发工作，生成《注释文档》
七：单元测试、集成测试、系统测试，生成《测试日志》
八：编写《用户使用手册》，交付并指导客户使用
课外参考
Ref: 深入业务成为更好的软件架构师——信息化建设图鉴一二例
Ref: 孙宇聪 《SRE: Google运维解密》
软件的终极目标是模拟业务
王概凯(Kevin)的《聊聊架构》，其中特别强调软件架构师应深入到业务中，并以业务的问题是否解决作为工作优良的判断标准。
-
- 在明确了业务主体后，业务目标自然就可以得到聚焦，
- 有了清晰的业务目标，就值得花精力来探知业务的生命周期，
- 接下来就可以像外科手术医生一样细致地实行架构拆分。
由此可见，软件架构师在实行架构拆分行为时，基本上都把业务从头到尾捋了一遍，否则势必陷入设计不足或过度设计的漩涡。
强调了“软件运行生命周期”的重要性
孙宇聪在高可用架构里提到的《SRE: Google运维解密》
在软件运行这样一个最为核心的生命周期中，发布更新的质量直接影响到企业信息部门的运维表现，结合孙宇聪的诸多建议我也列举一些值得注意的要点：
-
-
线下测试（Offline Test）。重点检查线下测试环境是否完善，除此之外还需要产品人员和开发人员的督促。除了一般的代码逻辑测试，尽量再兼顾到压力测试。
-
灰度发布（Gray Released）。指的是根据业务特点、数据特点来选择一批有极强代表性的线上服务器实例进行发布，其发布的比例可以考虑按 1%、10%，最后 100% 这一指数型方式来增长。这样有利于把新上线功能可能的不良影响降到最低，当然也可以作为小范围收集用户的反馈意见以待完善产品功能。灰度发布可以视作是上线前的最后一道安全防护机制。
-
回滚机制（Rollback）。一般来说用上一个版本的相关程序集进行覆盖即可，但有时还会出现数据格式的兼容性问题。比如数据库表字段的类型此前发生了变化，那这时候还需要有配套的回滚 SQL 脚本。另一种情形是新的变更内容把数据删掉了，回滚后数据也回不来了，这种情况是没有补救措施的，建议的做法是将程序代码分成两块逻辑，先发布第一段逻辑并记录好日志，等发现没有问题后再将删除的代码作为第二次发布。
-
End.
