【Part 3 在实践中思考】
8. 准备工作
完整案例讲述从项目的可行性分析阶段一直到实现阶段的整个过程。
8.1 案例说明
服务行业选一个案例。
8.2 了解问题领域
电力是怎么来的：发电；送电；变电；配电；用电 五个环节。
8.3 整理业务目标
业务目标又称为业务前景，是对要建设的系统的展望。
8.3.1 什么是涉众。
涉众是与要建设的业务系统相关的一切人和事。
8.3.2 发现和定义涉众
8.3.2.1 业主
业主是系统建设的出资方、投资者。
8.3.2.2 业务提出者
业务提出者是业务范围、业务模式和业务规则的制定者，一般是指业务方的高层人物，比如 CEO、高级经理等。
系统建设正是业务提出者经营目标和管理意志的体现。
8.3.2.3 业务管理者
业务管理者是指实际管理和监督业务执行的人员，一般是指中层干部，他们起到将业务提出者的意志付诸实施，并监督底层员工工作的作用。
8.3.2.4 业务执行者
业务执行者是指底层的业务操作人员，是与将来的计算机直接交互最多的人员。
他们最关心的内容是系统会给他们带来什么样的方便，会怎样改变他们的工作模式。
业务执行者的需求最为细节，系统的可用性、友好性、运行效率等与他们关系最多。
8.3.2.5 第三方
第三方是指与这项业务有关系的，但并非业务方的其他人或事。比如购物网站的网上银行支付，那么网上银行就是这个购物网站的第三方。
8.3.2.6 承建方
承建方，也就是你的老板。实际上老板的期望也是不容忽视的。
8.3.2.7 相关的法律法规
法律法规：
- 国家和地方的法律法规。
- 行业规范和标准。
例如服务行业建立客户档案，就必须保障客户的隐私权，系统设计时就不能够将涉及隐私的信息向非授权用户开放。
8.3.2.8 用户
用户是一个抽象的概念，指预期的系统使用者。
8.3.3 涉众分析报告。
系统分析员对项目范围内的涉众进行调查和访谈，形成涉众分析报告。
报告内容包括：涉众概要、涉众简党、用户概要、用户简档和消费者统计五个部分。
8.3.3.1 涉众概要
涉众概要首先为每个涉众编号，然后说明涉众的基本信息和涉众在系统中的角色。
在进行涉众分析的时候，最重要的是准确描述涉众情况和他们对系统建设的期望，而不是进入业务细节。
8.3.3.2 涉众简档
描述涉众在系统中承担的职责，以及涉众在系统中的成功标准。
8.3.3.3 用户概要
用户概要说明代表涉众使用系统的用户说明，这里的用户指的是计算机的预期操作人员，在很多情况下涉众并不一定是用户。
8.3.3.4 用户简档
用户简档用来对用户代表进行描述。将一些典型的用户代表的一些信息描述出来，这些信息对系统的建设者有着积极的指导意义。
8.3.3.5 消费者统计
消费者统计说明系统的预期使用人群和他们的特点，使用系统的频率和方式，消费者对此系统的普遍期望等。
8.4 规划业务范围
应当根据项目周期、项目成本、可行性分析等许多因素，衡量项目可以容纳的业务范围。
8.4.1 规划业务目标
- 取消一个业务目标。
- 调整一个业务目标。
8.4.2 规划涉众期望
规划手段：
- 取消一个涉众
- 减少一个涉众期望
- 调整一个涉众期望
8.5 整理好你的思路
业务范围规划好后，着手准备需求调研。
8.5.1 划分优先级
如何划分优先级？：可以为涉众和涉众期望分别用数字划分优先级，再用它们相乘的结果来排序。
8.5.1.1 涉众优先级标准
- 最高优先级，数值3
- 普通优先级，数值2
- 最低优先级，数值1
8.5.1.2 期望优先级标准
- 最高优先级，数值3
- 普通优先级，数值2
- 最低优先级，数值1
8.5.1.3 优先级矩阵
8.5.2 规划需求层次
人们对事物的理解总是由粗到细，由表及里的。
8.5.2.1 第一层次：业务架构
第一层次围绕业务背景、业务目标、业务目标人员、业务参与人员、组织结构、岗位设置等展开，由此搭建起对业务领域的第一了解。
8.5.2.2 第二层次：业务流程
针对每个业务目标，将参与这个业务目标的业务目标人员、业务参与人员、组织结构和岗位设置组织起来，描述业务流程的运转过程以及每一个参与元素在运转过程中的贡献和期望。
8.5.2.3 第三层次：工作细节
针对每个参与上述业务流程的参与者展开，描述他的工作细节，做什么，怎么做。有哪些规则、结果是什么。
8.5.3 需求调研计划
该计划规定了哪些优先级的期望在什么时候进展到什么需求层次，由谁来负责。
8.6 客户访谈技巧
8.6.1 沟通的困难
- 不要一开始陷入业务细节。
- 使用双方习惯的沟通方式。
- 客户时间有限，一次性搞定
- 会议记录
8.6.2 沟通技巧
- 建立平等的对话平台
- 做足准备工作
- 以我为主
- 改变沟通策略
- 被动型沟通者要善于引导。
- 把握需求节奏
- 记录与反馈
9. 获取需求
9.1 定义边界
9.1.2 现在行动：定义边界
9.2 发现主角
10. 需求分析
11. 系统分析
架构的英文是：Architecture
框架的英文是：Framework
【什么是软件架构】
- 软件架构师一种思想，一个系统蓝图，对软件结构组成的规划和职责设定。
软件架构的意义就是要将可逻辑划分的部分独立出来，用约定的借口和协议将它们有机的结合在一起，形成职责清晰、结构清楚的软件结构。
软件架构形成以后，就会有厂商根据软件架构来实现这个架构，开发出若干可执行的半成品，例如某设计模式的实现框架、接口的实现框架、传输协议的开发包等。
【什么是软件框架】
- 软件框架是软件架构的一种实现，是一个半成品。它通常针对一个软件架构当中某一个特定的问题提供解决方案和辅助工具。
架构师一个逻辑的构成，框架则是一个可用的半成品，是可执行的。
IBM 的 Websphere（框架）是遵循 J2EE 架构的实现。
MVC 是设计思想，将应用恒旭划分为实体、控制和视图三个逻辑部件。Struts 是实现该架构，提供半成品。
【软件架构的基本构成】
软件架构师一种思想，一个系统蓝图，是对软件结构组成的规划和职责设定。
【应用软件架构】
业务架构+软件架构=业务系统
【优化分析模型的关键点】
- 容易变化的需求
- 结构化和耦合度调整
- 交互集中点调整
【组件模型】
组件可以容纳分析类或者设计类。
【部署模型】
部署模型又称为实施模型。
12. 系统设计
12.1 系统分析与系统设计的差别
举例：
- 客户——我想要一面电视墙。
- 分析员——在这面墙上做一个褐色的背板。
- 在墙上钉一块水泥板，然后贴上褐色的墙纸。
12.2 设计模型
12.2.1 按图索骥——为新世界添钻加瓦
12.2.2 现在行动：将分析模型映射到设计模型
设计模型有必要么
- 视情况而定
12.3 接口设计
12.3.1 畅通无阻——构建四通八达的神经网络
接口决定了整个系统是否能正常运行，哪怕每个对象都是完美的。
12.3.2 现在行动：设计接口
面向对象的一大好处——接口与实现的分离。使我们考虑程序逻辑时不用考虑程序将怎样编写，而只考虑对象交互的接口。
接口的优势：一旦设计出结构良好、定义完善的接口，你将获得一个健壮、灵活、可扩展、易维护的系统。
整体上看，一个系统的优劣决定于接口而不是实现。
- 为单个对象设计接口
- 为具有相似行为的对象设计接口。
- 为软件各层次设计接口。
- 针对复杂的交互，可以考虑门面模式（Facade）。
- 门面模式的意图是在系统内抽象出高层的接口，外部系统通过接口访问系统内部而不是直接访问系统内部的类。
12.4 包设计
12.4.1 分工合作——组织有序世界才能更好
【自顶向下原则】
比如现实世界企业的组织结构。
包的组织结构是由软件层次构成。
分包时避免将界面类、逻辑处理类和数据处理类混在一个包里。
【职能集中原则】
意思是尽量将与一组业务功能有关的类分在同一个包里。
职能集中原则在软件世界里反映为 子系统、模块、字模块、功能模块的划分。
【互不交叉原则】
包与包之间的类尽量独立，不要让它们相互依赖。即便有依赖，也得是树状依赖而不是网状依赖。不要累死踢皮球现象。
13. 数据库设计
面向对象建模与关系数据建模两者所面对的领域和要解决的问题是根本不同的。
面向对象致力于解决计算逻辑问题，关系模型致力于解决数据的高效存取问题。
面向对象与关系模型表达了两种截然不同的时间观：
- 动态与静态
- 封装与开放
【相辅相成——面向对象的数据库设计】
聚合对象持久化可能会拆分多张表：比如公司由公司基本信息+部门LIst构成。
- 业务逻辑一体，但OR-Mapping会转换成两张表。
真正好的面向对象设计会分离业务逻辑和控制逻辑，在运行过程中业务对象与流程控制对象是独立加载并在流程控制框架下动态绑定的。
我们甚至可以将数据库视为保持数据的一种手段，而放弃数据库的约束，如主-外键关系。
- 但会牺牲性能，额外咨询关系管理框架。
【平衡的艺术——数据库设计的方法和策略】
- 明确数据库设计可以遵循两种方法：
- 面向对象的方法
- 只能看到对象的交互，时间和消息流的传递，而无法看到数据状态的变化——数据被封装起来了；
- 适合面向对象的分析方法，比如活动图、时序图等。
- 数据流建模方法
- 只能看到数据状态的变迁和引起这个变迁的激发点，无法看到引起这种变化的行为逻辑。
- 适合面向过程的分析方法。
- 面向对象的方法
【面向对象方法中的数据库设计，最佳实践】
- 首先采用面向对象的方法分析和设计系统，用纯对象模型去实现业务需求，无需考虑数据库设计。
- 业务需求实现后，定义需要持久化的对象，并为之建立数据模型，并描述对象模型到关系模型之间的映射关系。
- 根据非功能性需求针对数据存取的性能要求改进数据库设计
- 针对特殊需求进行特殊的数据库设计。
【OR-Mapping 策略】
任务：转换对象关系与实体关系，并且负责实现将其对象存储、更新、删除到关系型数据库中，或者从关系型数据库中查询出数据，并转换为对象。
作用：可以隔离面向对象与关系型数据库的差异，承担了翻译者和转换者的角色。
举例：Hibernate、ibatis
【关联关系的映射策略】
- 一对一和一对多关联
- 多对多关联
【聚合关系和组合关系的映射策略】
组合关系，整体消亡部分消亡。持久化时，可映射为父子表方式。
聚合关系，整体消亡部分存在。持久化时，映射为无关联的两张表合适。
【依赖关系的映射策略】
依赖关系是一种动态关系，表现为行为上的依赖而不是属性依赖。
依赖的目的是使用对方方法而不是属性。而方法是无须持久化的，因此依赖关系并无 OR-Mapping 的必要。
【对象——关系平衡策略】
- 没有强烈的关联共享需求，有限面向对象设计原则，牺牲部分关系数据库设计原则。
- 数据有性能要求，如海量数据或者频繁读写，优先考虑数据库性能，适当牺牲面向对象原则和持久化便利性。
- 数据存取的性能要求极高，可以完全牺牲面向对象的特性，在数据库层面寻求高效的数据库设计方案，甚至存储过程。
- 强烈的数据共享分享要求，如报表统计，面向对象和数据库均做考虑。
【数据库设计的重要性】
part 四 在提炼中思考。
道可道非常道。面向对象的分析设计绝不是简单的模板和步骤，前人的经验不是用来模仿和遵循的，而是用来提炼和创造的。
看到了，学会了，不是知识；如果只是学习然后复制，那么复印机就能干这事；
学习了，思考了，得出了自己的结论，才是知识。
15. 测试
【质量保证——新世界需要稳健运行。】
引入测试工具。
15.2 设计和开发测试用例
步骤：
- 确定用例；
- 确定测试范围的过程。
- 确定用例场景：
- 确定执行路径。
- 确定测试场景
- 确定测试因素（鱼骨图分析测试因素）
- 用户输入
- 运行时设置
- 环境设置
- 开发测试矩阵
- 开发和执行测试用例
16. 理解用例的本质
16.1 用例是系统思维
用例的一系列特征：
- 相对独立
- 有参与者
- 可观测和有意义
- 动宾短语形式出现
- 一个用例是一个需求单元、分析单元、设计单元。。。
什么是线性思维？
- 考虑问题只从一个角度线性地、顺藤摸瓜式地去思考和理解一个问题领域。也叫静态思维。
什么是系统思维？
- 系统是一个封闭的、由一系列相互关联、相互影响的物质构成的集合；
- 这个集合用一系列的过程、规则或规律来描述；
- 系统具有反馈和自我完善、动态平衡的特征。
系统思维是考虑系统内事物的互相影响而不是观察单个事物的变化，归纳
抽象系统内的运行规律而不是研究单个点的存在意义。
举例：麻雀被列为四害，大量捕杀引发第二年虫灾。
用例方法是一种系统思维方法。采用用例来分析系统，
我们就是使用系统观而不是线性观来看待软件。
16.2 用例是面向服务的
SOA 第一条准则便是：业务驱动服务，服务驱动技术。
18. 用例驱动与领域驱动
18.1 用例驱动与领域驱动的差异
无一例外都是通过一种方法定义（或建模）需求，再根据需求定义（或模型）来驱动后续的软件生产工作。
驱动意味着以此为核心，在此基础上推导出软件设计；你的开发计划、工作内容、管理活动，软件生产的一切要素都围绕着这个基础展开。
从原理上来说，用例驱动式一种由外而内，先招式后内功的思想。
领域驱动正好相反，它是一种呦内而外，先内功后招式的思想。它要求团队有资深业务领域专家，找出反映业务本质的那些事物、规则和结构，把它抽象化。
领域驱动方法带有理想主义色彩，试图从根本上解决问题，把业务袁丽华、标准化、抽象化，有了原理，再来应用。
领域驱动更有价值，用例驱动更为实用。
【建议】
- 如果无法摆脱以项目为中心的运营模式，在实际项目中应当采用用例驱动方法而不是领域驱动方法。
- 如果暂时无法达到行业深度，又想往行业领导者发展，那么应当建立研发中心，把实施项目与研发产品分离出来。
- 实施项目——积累业务知识
- 产品研发——把业务知识转化为领域模型和相应的产品。
- 如果行业深耕多年，有深厚业务知识背景，可以建立领域模型驱动的方法实施项目。
19. 理解建模的抽象层次。
抽象有两种：
- 自顶向下
- 自底向上
软件分析：
- 需求到分析，设计到实现时自顶向下
- 过程中归纳和总结的结果，自底向上。（接口设计、分包、重构）
【层次高低问题】
- 将食物按层次划分是人们归纳和理解事物的重要形式。
【层次不交叉问题】
- 所谓层次不交叉，是指在描述事物的过程中，同一层次的描述内容是等值的。
- 软件分析：用例粒度要统一
【如何决定抽象层次】
分析设计前，要预先确定有多少个抽象层次。
【抽象层次与 UML 建模的关系】
UML 建模是以用例为基础的，即用例驱动。
有了很好地层次定义，我们就能知道每一层上要解决的关键问题是什么。找到的用例都是用来解决这些问题的，除此之外的问题一概不考虑。
20 划分子系统的问题
20.1 划分子系统的问题
在许多项目里，子系统的划分是以用户部门或业务为依据的。如生产子系统、财务子系统、人力资源管理子系统。
20.3 如何划分子系统
子系统将系统分为若干个单元，这些单元：
- 可以独立预定、配置或交付
- 可以独立开发
- 可以在一组分布式计算节点上独立部署。
- 可以在不破坏系统其它部分的情况下独立地进行更改。
- 将系统分为若干单元，提供对关键资源的有限安全保护。
- 在设计中代表现有产品或外部系统。
21. 学会使用系统边界
对象是由边界来封装的；接口正式边界的体现。
边界类的实现，可能是界面，可能是接口，可能是传感器。
对象封装的结果是出现了一组接口方法，在应用程序中叫 API，在系统内部叫 SPI。
API 或 SPI 实质上就是该对象的边界，任何其他对象试图访问该对象时，必须经过边界并且遵守边界的规则。
【边界意识决定设计的好坏】
- 搅在一起的鸡蛋和个体分明的鸡蛋。
22. 学会从接口认知事物
22.1 怎样描述一件事物
通常，人们认知一件事物的最终目的是希望能够搞懂这件事物是什么，希望精确定义事物的每一个属性和每一种行为。
不论在分析、设计还是描述软件的过程中，接口以及接口之间的交互远比讨论对象内部实现更重要，是接口而不是对象实现决定了系统行为。
22.2 接口是系统的灵魂
每个边界就是一个接口，这个接口有着属性和行为，这是它所表现出来的样子。
这些属性和行为支撑起整个系统大厦，而对象内部的实现可以改变、可以替换，却无法影响整个系统大厦。
就像无论怎样装修内部房间，也不可能改变整栋大楼的结构。
- 边界分析定义接口形式
- 时序图里用接口描述系统行为
23. 学会正确选择
23.1 屁股决定脑袋——学会综合权衡
立场决定思想，在这里指在分析过程中，分析者也应当根据实际情况变换分析立场，来获得对系统多方面的了解。
比如分析车的抽象角度：外观 or 实用。
实际项目中，PM，PD，架构师，设计师，开发员，测试员都具有不同的立场。
- PM 追求时间和成本；
- PD 追求业务实现；
- 架构师追求扩展和稳定；
- 设计师追求程序结构；
- 开发员追求便捷；
- 测试员追求质量；
SWTO 方法帮助分析
- S：Strength 优点
- W：Weakness 缺点
- T：Threat 威胁
- O：Opportunity 机会
多种方案的 SWTO 分析！
23.2 理辩则明——学会改变视角
图书管理项目：读者视角 or 图书馆视角
24. 学会使用设计模式
设计模式是学习面向对象设计不可回避的问题。
本质上，设计模式是面向对象设计原则和方法的应用，是在具体实践过程中解决某类问题而产生的经验总结和最佳时间。
若有收获，就点个赞吧
0 人点赞
