[Design Patterns] 3. Software Pattern Overview

学前复习

• 搜索：跟我学UML建模工具StarUML 系列文章

第一部分，下载和安装及破解StarUML工具软件

第二部分，StarUML工具软件的主要功能界面和UML图的创建示例

• 第一篇、[Design Patterns] 01. Before Design Patterns - UML

结合starUML，在项目中如何灵活使用各种Diagram。

• 第二篇、[Design Patterns] 02. Design principle and Software Pattern

在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运维解密》

Ref: 王概凯(Kevin) 《聊聊架构》

软件的终极目标是模拟业务

王概凯(Kevin)的《聊聊架构》，其中特别强调软件架构师应深入到业务中，并以业务的问题是否解决作为工作优良的判断标准。

• • 在明确了业务主体后，业务目标自然就可以得到聚焦，
  • 有了清晰的业务目标，就值得花精力来探知业务的生命周期，
  • 接下来就可以像外科手术医生一样细致地实行架构拆分。

由此可见，软件架构师在实行架构拆分行为时，基本上都把业务从头到尾捋了一遍，否则势必陷入设计不足或过度设计的漩涡。

强调了“软件运行生命周期”的重要性

孙宇聪在高可用架构里提到的《SRE: Google运维解密》

在软件运行这样一个最为核心的生命周期中，发布更新的质量直接影响到企业信息部门的运维表现，结合孙宇聪的诸多建议我也列举一些值得注意的要点：

• • 线下测试（Offline Test）。重点检查线下测试环境是否完善，除此之外还需要产品人员和开发人员的督促。除了一般的代码逻辑测试，尽量再兼顾到压力测试。

  • 灰度发布（Gray Released）。指的是根据业务特点、数据特点来选择一批有极强代表性的线上服务器实例进行发布，其发布的比例可以考虑按 1%、10%，最后 100% 这一指数型方式来增长。这样有利于把新上线功能可能的不良影响降到最低，当然也可以作为小范围收集用户的反馈意见以待完善产品功能。灰度发布可以视作是上线前的最后一道安全防护机制。

  • 回滚机制（Rollback）。一般来说用上一个版本的相关程序集进行覆盖即可，但有时还会出现数据格式的兼容性问题。比如数据库表字段的类型此前发生了变化，那这时候还需要有配套的回滚 SQL 脚本。另一种情形是新的变更内容把数据删掉了，回滚后数据也回不来了，这种情况是没有补救措施的，建议的做法是将程序代码分成两块逻辑，先发布第一段逻辑并记录好日志，等发现没有问题后再将删除的代码作为第二次发布。

End.