软件体系结构笔记

软件开发流程

1.软件开发流程_简介

1.1从管理角度

即从业务和经济的角度来看，软件的生命周期包括四个主要阶段:

起始阶段:有一个好的想法：具体构想产品的设想和它的业务案例，确定项目的范围 。

细化阶段: 计划必要的活动和所需资源，具体确定功能并设计构架 。

构建阶段: 构建产品， 发展最初的设想、构架和计划，直到一个能够交付给用户的产品（完毕后的设想）完毕。

移交阶段: 将产品移交用户使用，包含：交付、培训、支持、维护，直到用户惬意。

1.2从技术角度

1.需求： 需求就是我们需要做些调研，挖掘用户想要的功能，来帮助用户完成什么事情，在进一步探讨，实现用户的更多需求

2.设计： 在需求的基础上，开展项目设计，如业务系统详细设计/结构设计/数据库设计…

3.开发： 根据设计来完成具体的实现(编码)，自我测试

4.测试： 功能测试/性能测试/其他测试，问题修复后再测试，直到没有出现问题为止

5.上线： 将项目部署，正式环境使用，交付用户使用

1.新项目上线 ：将项目打包上传服务器启动

2.迭代项目：在已有项目上新增功能/变更功能

6.运维： 软件上线后，线上监控，维护，确保系统的可用性

运维工程师处理，但是我们开发时需要懂一些

1.3迭代

用户建议增强功能、用户环境的改变、重要技术的变更，以及应对竞争的需要

每次迭代包含步骤：计划、分析、设计、实施和测试

迭代： 举例拿了一块地，修房子(小区) 第一期，反响很不错，建议再修一起，

产生了一个迭代

开发商：迭代建筑 ~

备注：不是每一个项目都有迭代过程

###2.软件开发流程_详细介绍

需求

1.相关系统分析员向用户初步了解需求，然后用相关的工具软件列出要开发的系统的大功能模块，每个大功能模块有哪些小功能模块，对于有些需求比较明确相关的界面时，在这一步里面可以初步定义好少量的界面。

2.系统分析员深入了解和分析需求，根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档。这次的文档会清楚列出系统大致的大功能模块，大功能模块有哪些小功能模块，并且还列出相关的界面和界面功能。

3.系统分析员向用户再次确认需求 （反复确认）

设计

A概要设计(架构设计)

需要对软件系统进行概要设计，即系统设计。概要设计需要对软件系统的设计进行考虑，包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为软件的详细设计提供基础。

B.详细设计(数据库设计（非必选）/接口详细设计)

实际设计： 1.架构设计 2.概要设计 3.数据库设计 4.详细设计

开发

主要指软件编码阶段，开发者根据《软件系统详细设计报告》中对数据结构、算法分析和模块实现等方面的设计要求，开始具体的编写程序工作，分别实现各模块的功能，从而实现对目标系统的功能、性能、接口、界面等方面。在规范化的研发流程中，编码工作在整个项目流程里最多不会超过1/2，通常在1/3的时间，所谓磨刀不误砍柴功，设计过程完成的好，编码效率就会极大提高，编码时不同模块之间的进度协调和协作是最需要小心的，也许一个小模块的问题就可能影响了整体进度，让很多程序员因此被迫停下工作等待，这种问题在很多研发过程中都出现过。编码时的相互沟通和应急的解决手段都是相当重要的，对于程序员而言，bug永远存在，你必须永远面对这个问题！

####测试

测试编写好的系统。交给用户使用，用户使用后一个一个的确认每个功能。软件测试有很多种：按照测试执行方，可以分为内部测试和外部测试；按照测试范围，可以分为模块测试和集成测试；按照测试条件，可以分为正常操作情况测试和异常情况测试；按照测试的输入范围，可以分为全覆盖测试和抽样测试。以上都很好理解，不再解释。总之，测试同样是项目研发中一个相当重要的步骤，对于一个大型软件，3个月到1年的外部测试都是正常的，因为永远都会有不可预料的问题存在。完成测试后，完成验收并完成最后的一些帮助文档，整体项目才算告一段落，当然日后少不了升级，修补等等工作

非必现bug： 项目中测试过程没有出现，或者这个流程测试过，当时没有问题，后来有问题

必现bug

上线： 开发人员，开发好，测试通过之后，会编写部署文档，部署文档内容：1.项目(软件)的存放地址 (ftp) 软件迭代管理目录 2.如何部署 （相关的配置 Ip 目录 其他线上的配置） 3.如何启动(shell脚本) ：目标时： 让运维人员能够按照流程执行 项目的先后启动顺序

####交付

软件测试证明软件达到要求后，软件开发者应向用户提交开发的目标安装程序、数据库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、设计报告、测试报告等双方合同约定的产物。

《用户安装手册》应详细介绍安装软件对运行环境的要求、安装软件的定义和内容、在客户端、服务器端及中间件的具体安装步骤、安装后的系统配置。

《用户使用指南》应包括软件各项功能的使用流程、操作步骤、相应业务介绍、特殊提示和注意事项等方面的内容，在需要时还应举例说明。

操作步骤：完成某个业务，每一步的操作

相应的业务介绍：需求报告中要求的重点的需求，进一步介绍

特殊提示： 必须的，我们一般都是定义一个异常码 (100002: 操作错误)

注意事项：可能会导致项目问题的注意事项

举例： 认证登陆：输入5次密码，都错了，这个时候，系统会封号

项目交付前流程：先交定金30%，项目验证通过之后，付50%，尾款20%

软件开发中应具备的思想

1.欲速则不达~

A. 不推荐拿到需求马上就开发，先构思，先想清楚

B. 减少做无用功

2.先验证再答复

A. 技术先写demo,验证后再答复

B. 不太确定的需求，不能立即答复

3.胸中成竹

所有流程/业务场景我们得了然于胸，做好准备

如果作为一个产品经理一样得考虑，每个场景，和每种场景的解决方式

4.新技术的使用

并不是使用最流行的技术就是最好的，根据项目的具体情况而言

没有太熟练的技术，不建议使用 。

5.解决问题的方法~开发人员会遇到各种各样的问题

A. 看下论坛 /百度

B. 请教大神

C. 如果请教大神都解决不了怎么办 考1思想

D. 如果不能转换为已解决的问题，向上反馈

软件开发中常用的辅助工具

1. Notepad++

记录文本，使用 ，不会自动销毁

2. HiJson/json格式化工具

推荐在线的json格式化工具

3. XMind/百度脑图/迅捷画图/Office Visio/axure

画流程图/结构图/思维导图/时序图

4. Beyond Compare

用户文本/文件夹内容比较 SVN:比较线上的文件不同之处

5.有道云笔记

用户记录日常文件/总结/日志/灵感

6. 有道词典

翻译，变量名称

7. Xshell

链接服务器的工具（必备工具）

8. TeamViewer

控制对方或者请求对方控制自己电脑/协助完成某个事

需求与需求分析

一．需求收集归纳

1. 初步收集

收集需求~用户说我现在系统/软件

2. 归纳

把用户的需求整理成一个文档

3. 需求的分析

概念：把计划中的软件需求进行一个可行性分析，细化/求精 ，分配软件元素(软件模块)需求过程中最后一步，确定了系统必须要完成的工作。

举例： 需要给家禽养殖场开发一个温感控制系统

提问： 到底需要什么样子的温感控制系统 /p>

1.准确描述用户的需求以及功能

2.帮助客户挖掘需求

3.分析客户需求的可行性 同时给出一个专业的设计建议

4. 需求分析的难点

1.客户说不清楚需求 2.需求本身是具有变动性的 3.沟通有误

5. 需求分析的分类：

功能需求：用户最直观的最主要的需求

非功能性需求：响应时间/存储效率/页面美观

领域的需求：系统应用领域，基本会出现的问题，针对这些问题，该领域存在的潜在需求

6. 需求分析的不同层次 （了解）

业务需求：反应了组织机构对系统/产品有高层次的要求

用户需求：需求文档要完成的任务

功能需求(分功能性需求)：开发人员必须实现的软件功能

7. 评估：

这个过程实际上，需要系统分析员,产品经理，架构，项目经理，开发团队

8. 需求分析的方法

1. 功能分析法： 定义各种功能与功能之间的关系 ，以及子接口

   2.数据流分析法： 分析数据流程

2. 信息建模 实际上就是面向对象的抽象过程

powerDesger

二．需求补充：

如果有页面，最好做出原型图(画流程图)/墨刀或者参考系统/链接

目标：确定好需求是为了尽量去解决需求变更的问题

需求文档，没有固定的模板,各个公司都不同，没有最好，只有更好

备注：无法彻底解决，总有意想不到的业务情况变动或新增

概要/架构设计

一．架构概念

1.定义：

通用定义：计算机内部组件的组合,整合和交互

此处的定义：实现某个软件/系统，需要组件整合和组件的交互方式

2.架构设计详细分解：

架构设计包括了功能性架构和技术架构设计两个部分的内容

功能性架构解决业务流程和功能问题。(举例 登陆认证系统复用)

其他架构扩展：

2.模块件的集成架构，分析完成后，各个模块之间的接口基本就整理出来了。

(考虑到复用性)

解释：

模块之间的接口：服务对外部提供了接口，外部通过这个接口，发起请求(携带数据)，服务接受到之后，

进行数据处理，相应的响应消息返给调用方

同步：

异步：

可以再回调通知

3.设计事务，缓存，异常 ，性能，可用性，容错能力

扩展： 分布式事务

缓存： 减少数据库压力，提高效率 ，经常用，公共的数据

异常消息提醒（书写用户手册时提到）

通知管理者： 短信 邮件

性能： 硬件方面 ，横向扩展多台服务器

软件方面 ，缓存、队列，数据库层面

容错能力：出现错误后，对系统的影响程度

四．如何书写架构设计说明书

1. 软件实现所需硬件要求

例如：

*硬件类型*	*数量*	*参数*	*要求*
数据库服务器	3	2*12core32G300G	物理机
应用服务器	2	2cpuMem:8G40G	物理机或者虚拟机
内部网络			千M以太网或以上

2. 软件的构件组成以及版本

	*名称*	*版本*
操作系统	Linux Redhat	6.4
关系型数据库	Oracle	11g以上
Web服务器	Tomcat	8.0.18以上
运行环境	JDK	1.7以上
其他软件	Spring	4.1.7
Log4j	1.2.14
junit	4.1.2
mybatis	3.2.7

3. 物理架构

为什么要做概要设计/h4>

为了项目最终的目的，为了保证实现的功能不会偏差，即使性能上，易用性上有问题，不影响整理功能 。

数据库相关设计

一．案例实际处理

1.教学管理系统

基本需求：

某学校设计学校教学管理系统，学生实体包括学号、姓名、性别、生日、民族、籍贯、简历、入学日期，每名学生选择一个主修专业，专业包括专业编号、名称、类别，一个专业属于一个学院，一个学院可以有多个专业。学院信息要存储学院号、学院名、院长。教学管理要管理课程表、学生成绩表。课程包括课程号、课程名、学分，每门课程由一个学院开设。学生选修的每门课程获得一个成绩。

如何设计数据库/h5>

1.进行数据抽象

2.数据表示：

学生实体(学号、姓名、性别、生日、民族、籍贯、简历、入学日期，专业编号)

专业实体(专业编号、名称、类别，学院号)

学院实体（学院号、学院名、院长）

课程实体(课程号、课程名、学分，学院号)

成绩单实体(学号，课程号，成绩)

备注： 做了一个抽象过程和一个关联关系

3.表达方式：

用英文来代替（s_id,p_id,c_id）

4.写入数据库中

4.1创建数据库

4.2创建表

数据库第一范式:比较有用，

数据冗余关系 不建议 但是实际情况比较常见

5.数据分析

2.权限管理系统

基本需求：多个用户，每个用户最多只能有一种角色，每个角色可以有多种权限 。

3.评论留言系统

任何人都可以对某好友动态进行多次评论，该好友可以在该评论下进行一次回复 。

二．逆向看理论知识

数据库实施中：增量上线

新项目上线

数据库维护：垃圾数据处理，数据备份，数据的转储

三．思考数据库设计到底应该是做什么/h3>

一．引擎选择

Mysql

Innodb:支持事务

Mysam：查询

二．数据库表的设计(范式概念)

遵循范式概念 ，但是怎么方便怎么来~

三．sql语句的优化

A. 优化思路： 经量不用关联查询

Select id

…

详细设计

实现功能的具体处理办法和业务逻辑/流程

前/后端的逻辑

详细设计和业务逻辑密不可分，要想写出详细设计，必须要清楚理解到业务逻辑 。

安卓：

ios：

服务端：

1.登陆： 输入手机号码 –>获取验证码

2.验证码校验

3.服务端给出响应 –

详细接口文档编辑：

http://www.docway.net/dashboard

评估/完善

一．软件设计的评估时机

1.有初步需求后会先进行一次需求评估

2.架构/概要设计后，评估

3.详细设计(数据库/接口设计)再次评估

二．评估时机

为了再次验证设计是否有误，大方向上是否有问题

三．从哪些方面评估呢 /h3>

架构方面：

软件架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策。它也可以灵活地运用于对软件架构进行评审等工作中。

1 软件架构评估的方法

业界已开发出多种软件架构评估的方法，按基于的技术手段来看，可以分为三类：基于调查问卷或检查表的方式、基于场景的方式和基于度量的方式。

（1）基于调查问卷或检查表的方式：该方式的关键是要设计好问卷或检查表，它充分利用系统相关人员的经验和知识，获得对架构的评估。其缺点是在很大程度上依赖于评估人员的主观推断。

（2）基于场景的方式：基于场景的方式由 SEI 首先提出并应用在架构权衡分析法（Architecture Tradeoff Analysis Method，ATAM）和软件架构分析方法（Software Architecture Analysis Method，SAAM）中。它是通过分析软件架构对场景（也就是对系统的使用或修改活动）的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。下节将对ATAM 进行重点介绍。

（3）基于度量的方式：它是建立在软件架构度量的基础上的，涉及三个基本活动，首先需要建立质量属性和度量之间的映射原则，即确定怎样从度量结果推出系统具有什么样的质量属性；然后从软件架构文档中获取度量信息；最后根据映射原则分析推导出系统的质量属性。它能提供更为客观和量化的质量评估，但它对评估人员及其使用的技术有较高的要求。ATAM 中也使用了度量的思想（度量效用）。

2 架构的权衡分析法

从技术角度对软件架构进行评估，旨在通过分析来预见软件的质量；通过分析来创建、选择、评估与比较不同的架构。例如，Kazman 等人在 2000 年提出的架构的ATAM方法。 ATAM方法不但能够揭示架构如何满足特定的质量需求（例如，性能和可修改性），而且还提供了分析这些质量需求之间交互作用的方法。使用 ATAM 方法评价一个软件架构的目的是理解架构设计满足系统质量需求的结果。

ATAM 产生如下结果。

（1）一个简洁的架构表述：ATAM 的一个要求是在一小时内表述架构，这样就得到了一个简洁、可理解的、面向普通项目关系人的架构表述。它是从架构文档中提炼形成的。

（2）表述清楚的业务目标。

（3）用场景集合捕获质量需求。

（4）架构决策到质量需求的映射。

（5）所确定的敏感点和权衡点集合：这个集合是一些对一个或多个质量属性具有显著影响的架构决策。如：备份数据库就是这样一个架构决策，它对可靠性产生正面影响，而对系统性能产生负面影响，因此需要进行权衡。

（6）有风险决策和无风险决策。

（7）风险主题的集合。找到这些风险主题旨在采取相应的措施。

（8）产生一些附属结果。评估过程形成的文档（经受住了评估的考验）可以作为经验保留下来。

（9）还产生一些无形结果，如能够使项目关系人产生“团队感”，提供了一个交流平台和沟通渠道，使大家更好地理解架构（优势及弱点）。

3 成本效益分析法

在大型复杂系统中最大的权衡通常必须考虑经济性，因此，需要从经济角度建立成本、收益、风险和进度等方面软件的“经济”模型。成本效益分析法（the Cost Benefit Analysis Method，CBAM）是在 ATAM 上构建，用来对架构设计决策的成本和收益进行建模，是优化此类决策的一种手段。CBAM 的思想就是架构策略影响系统的质量属性，反过来这些质量属性又会为系统的项目关系人带来一些收益（称为“效用”），CBAM 协助项目关系人根据其投资回报（ROI）选择架构策略。CBAM 在 ATAM 结束时开始，它实际上使用了 ATAM 评估的结果。

CBAM 的步骤如下:

（1）整理场景。整理 ATAM 中获取的场景，根据商业目标确定这些场景的优先级，并选取优先级最高的 1/3 的场景进行分析。

（2）对场景进行求精。为每个场景获取最坏情况、当前情况、期望情况和最好情况的质量属性响应级别。

（3）确定场景的优先级。项目关系人对场景进行投票，其投票是基于每个场景“所期望的”响应值，根据投票结果和票的权值，生成一个分值（场景的权值）。

（4）分配效用。对场景的响应级别（最坏情况、当前情况、期望情况和最好情况）确定效用表

（5）架构策略涉及哪些质量属性及响应级别，形成相关的策略—场景—响应级别的对应关系。

（6）使用内插法确定“期望的”质量属性响应级别的效用。即根据第 4 步的效用表以及第 5 步的对应关系，确定架构策略及其对应场景的效用表。

（7）计算各架构策略的总收益。根据第 3 步的场景的权值及第 6 步的架构策略效用表，计算出架构策略的总收益得分。

（8）根据受成本限制影响的 ROI（Return On Investment，投资报酬率）选择架构策略。根据开发经验估算架构策略的成本，结合第 7 步的收益，计算出架构策略的 ROI，按 ROI 排序，从而确定选取策略的优先级。

详细设计（接口设计）方面：

面向对象软件设计原则：

A．单一职责原则（SRP）：

一个类应该有且只有一个改变的理由。也就是解决职责不清的问题，通俗地讲，既当爹又当妈这种行为用在软件设计中是不可取的。采用这一原则进行设计的最大好处是提高软件的可靠性与可维护性。

B．开放—封闭原则（OCP）：

在不用修改原有类的基础上就能扩展一个类的行为。如何正确理解“开放与封闭”，其对谁“开放”对谁“封闭”是我们理解这一原则的最大困难之处。它强调的重点在于“对于扩展它是开放的，对于修改它是封闭的”，其实也就是隔离变化，既达到职责单一又达到了扩展的目的。

C．替换原则（LSP）：

派生类要与其基类自相容。也就是说“子类型必须能够替换掉它们的基类型”。这一原则其实是对OCP原则的扩展，它强调的重点其实就是“父为子纲”。没有父亲也就没儿子，这种继承关系始终如一，不得改变。这一常理在这一原则中倒是得到了很好的体现。

D．依赖倒置原则（DIP）：

依赖于抽象而不是实现。还有一种说法：抽象不应该依赖于细节，细节应该依赖于抽象。就我个人的观点来讲，我不喜欢后面这种说法。它不简洁也容易让人误解。谁的抽象谁的细节藤摸瓜，瓜是抽象，藤是细节。其实这里面包含了归纳的思想，那就是从细节上抽象出其本质的东西。我们依赖的就是这个抽象本质，而不是它的具体实现细节。这又回到我上一原则所讲的“父为子纲”。

E．接口隔离原则（ISP）：

客户只要关注它们所需的接口。说得明白一点就是，“不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构”。如果我们把接口理解成角色，一个接口只是代表一个角色，每个角色都有它特定的一个接口，每个角色都服务于其客户端对象。那么用“投其所好”这个成语来形容这一原则，我觉得再恰当不过。虽然其意含贬义，但是它定制化服务、个性化服务则值得我们学习。这一原则强调了对软件实体通信之间的限制，它限制了通信的宽度，同时提供了一个指导化的设计思想，就是说通信要尽可能的窄，只投其所好。遵从这一原则带给我们的好处是：在软件系统功能需要扩展时，其修改的压力会最小。

实际呢/p>

所有人坐在一起吃下午茶-全凭经验和自己的理解情况

最终目的： 达成统一思想，解决大家的分歧 。

软件评估的结果：完成时间/内部的问题

开发前准备工作

1. 环境的安装搭建

JDK版本与项目运行版本统一

提问： 1.6编辑的程序是否可以在1.8上运行 本向下兼容

提问：怎么验证是否安装成功

Eclipse安装 /sts安装

Maven仓库安装

存放Jar包 以及jar包管理

svn权限申请/配置

管理项目版本的工具

GIT

2. 梳理/熟悉《设计文档》

3.给自己制定开发计划

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mrIoCXm7-1594531077347)(file:///C:TMPksohtml6556wps18.jpg)]

4. 计划原则 （从主体出发 – 局部方法）

意思是：准备写代码，应该先写那一部分呢/p>

开发中注意事项

1. 写注释

作者

时间

版本号

功能

场景

写注释原则： 1.有意义 2.正确描述 3必须最新

2. 命名规范

a) 方法命名采用大小写混合的形式。以小写字母开头，名字中其他单词的首字母以大写字母开头， 所有其它的单词都为小写字母；

b) 方法的命名应该能描绘出方法的作用和功能，方法的名字建议使用祈使动词或者动词短语；

selectUserById

c) 获取或者设置类的某种属性的方法显式的命名为 getProperty（）或者 setProperty（）。其 中 property 是指类的属性的名字；

d) 用于判断类的布尔属性的方法要显式的命名为 isProperty（），property 是指类的属性的名 字；

isEntiy

e) 用正确的反义词组命名具有互斥意义的变量或相反动作的函数。

Int num;

Int notNnum;

3. 风格：

A. 缩进 Tab

B. 空格

C. 对齐

D. 空行

备注：可以参考阿里的开发规范

4. 记得备份/即使可以自动保存-注意项

5. 版本上传/下载注意

6. 开发中可以配置的尽量选择配置，代码要写得活络一些

7. 开发时考虑到扩展性

例如：功能性代码和工具类代码区分开

8.开发中有问题及时反馈，很多开发做不到这一点

来源：E?????…