目录
一.软件开发的生命周期总括
二.项目架构分类
C/S架构
B/S架构
三.详解软件需求
需求分类
需求获取
需求分析
四.详解面向对象分析（OOA）
概念理解：
统⼀建模语⾔UML
UML的重要组成部分：
⽤例图的元素
识别参与者
合并需求获得⽤例
细化⽤例描述
定义概念类
确定类之间的关系
为类添加职责
建⽴交互图
软件需求规格说明书
一.软件开发的生命周期总括
软件⽣命周期中以划分为可⾏性研究、需求分析、概要设计、详细设计、实现、组装(集成)测试、
确认测试、使⽤、维护、退役10个阶段，如下图：
我们对软件开发的过程进行简单易懂的描述：
可⾏性研究：简单来说，可行性研究就是对我们所要设计软件使用当前技术能否完成，完成消耗的时间和资本是否在合理范围内，软件的功能是否能解决当前存在的问题，当前软件的开发是否能给公司带来正面效益。
需求分析：分析软件的功能和效率，对整个软件的开发起决定性作用，最后根据软件的功能和效率生成软件需求规格说明书
概要设计：设计软件的公共部分，包括接口，协议和约束（总体约束），主要对程序进行一个总体的设计，不涉及各个功能的细节实现
详细设计：对软件的各个业务和流程进行详细的设计，包括每一个业务的具体操作和设计
实现：对每个业务进行实现
组装(集成)测试：对软件进行部署，测试所有功能
确认测试：让用户确认所有功能是否符合预期，对整个软件进行验收
维护：通过各种必要的维护活动使系统持久的满⾜⽤⼾需要
退役：终⽌对软件产品的⽀持，软件停⽌使⽤
二.项目架构分类
一般项目的架构主要分为两种：C/S架构和B/S架构
C/S架构即客⼾端 / 服务器架
B/S架构即浏览器 / 服务器架
C/S架构
C/S 架构全称是客⼾端 / 服务器(Client / Server)架构，是常⽤的两层架构。客⼾端需要安装客⼾
端软件，服务端程序运⾏在服务器上，提供Socket或数据库服务。
优点：
• ⼤部分业务都可以在客⼾端完成，充分利⽤本地的计算机资源
• 响应速度快
• 个性化定制能⼒强
• ⾯向相对固定的⽤⼾群，对信息安全的控制能⼒强
缺点：
• 需要安装客⼾端才能使⽤
• 维护成本⾼，任何⼀台电脑上的客⼾端出现问题都需要进⾏维护，升能过程繁琐
B/S架构
B/S架构全称是浏览器 / 服务器(Browser/Server)结构，分为Web浏览器、服务器程序、数据库服
务三部分，可以理解为是对C/S架构⼀种改进。由于所有的业务逻辑都由服务器程序处理，所以客⼾端 仅使⽤浏览器就可以完成所有操作，⼤⼤降低了客⼾端的维护成本。
我们目前使用java设计的程序属于BS架构
优点：
• 客⼾端零维护，只需要安装⼀个浏览器即可
• 所有业务都集中在服务器端，业务扩展⾮常⽅便
• 维护成本低，只需要维护服务器即可
缺点：
• 通过⽹络发送请求和接收响应，受⽹络影响较⼤
• 服务器安全与业务处理能⼒需要花费很⼤精⼒与成本
• 不同浏览器⽀持不尽⼈意
三.详解软件需求
需求分类
a. 业务需求：指反映企业或客⼾对系统的⽬标要求，通常来⾃与企业内部，即软件的主要业务
b. ⽤⼾需求：描述的是⽤⼾的具体⽬标，或⽤⼾要求系统必须能完成的任务。（除业务需求之外的用户自己的需求）
c. 系统需求：从系统⻆度来说明软件的需求，包括功能需求(系统必须实现的功能)、⾮功能需求
(⽐如软件的质量，可维护性，效率等等)和设计约束(交付时的⼀些限制条件，⽐如必须采⽤国 有⾃主知识产权的数据库，必须运⾏在某个操作系统下)等等。
需求获取
需求获取的⽅式主要有以下⼏种：
a. ⽤⼾访谈：最基本的⽅式。
b. 问卷调查：由于对⽤⼾进⾏逐⼀访谈⽐较耗时且⽤⼾时间不⼀定允许及时参与访谈，所以可以 预先准备问卷调查表让⽤⼾填写，再根据结果进⾏⼩范围访谈，可以看做是对⽤⼾访谈的⼀种 优化。
c. 采样：对特定种群进⾏采样，研究所选出的样本，得到有⽤信息。对于信息系统的开发，现在 ⽂档就是采样种群。
d. 情节串联板：通过⼀系统图⽚、幻灯⽚来进⾏讲解，说明系统应该如何运⾏。
需求分析
获取需求后，进⾏具体的需求分析⼯作，最终形成软件需求规格说明书做为向下⼀个阶段交付的成果
a. 绘制系统上下⽂范围关系图：⽤于定义系统与系统外部实体间界限和接⼝的简单模型，为需求
确定范围；
b. 创建⽤⼾界⾯原型：可以通过快速开发⼯具开发⼀个原型或者通过幻灯⽚、Flash等演⽰⼯具制 作⼀个演⽰原型，甚⾄可以通过纸笔画出⼀些关键的界⾯接⼝⽰意图，从⽽帮助⽤⼾更好的理 解要解决的问题，理解系统；
c. 分析需求的可⾏性：对获取到的需求进⾏成本、性能和技术实现⽅⾯的可⾏性研究，以及是否 与其他的需求存在冲突，是否有对外部的依赖等；
d. 确定需求的优先级：是制订迭代计划的⼀个重要的依据，可以使⽤满意和不满意指标进⾏说 明。满意度表⽰当需求被实现时⽤⼾的满意程度，不满意度表⽰当需求未被实现时⽤⼾的不满 意程度；
e. 为需求建⽴模型：表现形式主要是图表加上少量的⽂字描述，图形化的描述使需求更加清晰、 易懂。需求分析模型主要描述系统的数据、功能、⽤⼾界⾯和运⾏的外部⾏为，并不会涉及软 件的具体实现细节，同时，为后续的软件设计提供了系统的表⽰视图；
f. 创建数据字典：对系统⽤到的所有数据项和结构进⾏定义，以确保开发⼈员使⽤统⼀的数据定 义
四.详解面向对象分析（OOA）
概念理解：
1 ⾯向对象分析(OOA)
发⽣在需求分析阶段，解决“做什么”的问题，主要任务是确定对象的属性与⽅法，对象与对象
之间的关系，各个操作的具体流程，但不考虑系统具体实现有关的因素；
2.2 ⾯向对象设计(OOD)
发⽣在系统设计阶段，解决的是“怎么做”的问题，其基本思想包括抽象、封装和可扩展性，其中可扩展性主要通过继承和多态来实现。主要任务是把实现对象进⾏⼯程化规范，管理程序内部各部 分的相互依赖，为⾯向对象编程提供指导与依据；
2.3 ⾯向对象编程(OOP) 发⽣在系统开发阶段，使⽤
统⼀建模语⾔UML
UML(Unified Modeling Language)是⼀种易于表达、功能强⼤且普遍适⽤的建模语⾔，它的
作⽤不限于⽀持OOA和OOD，还⽀持从需求分析开始的软件开发全过程。
UML的重要组成部分:
事物：事物也称为建模元素，包括结构事物、⾏为事物、分级事物和注释事物，这些事物是 UML模型中最基本的OO构造块；
◦ 关系：UML⽤关系把各个事物结合在⼀起，主要的关系有：依赖(dependency)、关联
(association)、泛化(generalization)、实现(realization)；
◦ 图：主要包括类图、对象图、构件图、组合结构图、⽤例图、顺序图、通信图、定时图、状态 图、活动图、部署图、制品图、包图、交互概览图等。
从⽤⼾的⻆度来看，他们并不想了解系统的内部结构和设计，他们关⼼的是系统所能提供的服
务，把从⽤⼾那⾥获取的需求记录下来，进⾏合成与提炼，从⽽建⽴⽤例模型。在OOA⽅法中，构 建⽤例模型⼀般需要经历以下阶段，分别的，识别参与者、合并需求获得⽤例、细化⽤例描述和调 整⽤例模型，其中前三个阶段是必需的。
⽤例图的元素
⽤例是⼀种描述系统需求的⽅法，在⽤例图中，主要包括参与者、⽤例和通信关联三种元素：
如图所⽰：
参与者：参与者是指存在于系统外部并与系统进⾏交互的任何事物，既可以是使⽤系统的⽤⼾，也可以是其他外部系统和设备等；
⽤例：指在系统中执⾏的动作，这些动作将⽣成参与者可⻅的结果。也就是说⽤例表⽰系统所 提供的服务，它定义了系统是如何被参与者所使⽤，描述的是参与者为了使⽤系统提供的服务 与使⽤发⽣的⼀段对话；
通信关联：表⽰的是参与者和⽤例之间的关系，或者⽤例与⽤例之间的关系。箭头所指⽅是对 话的被动接受者，箭尾所指⽅是对话的主动发起者，如果不想强调对话中的主动与被动关系， 可以使⽤不带箭头的关系实线。
识别参与者
参与者是与系统交互的所有事物，不仅可以由⼈承担，还可以是其他系统和硬件设备，要注意的是，参与者⼀定在系统之外，不是系统的⼀部分。执⾏系统功能的参与者可能有多个，有主次之分，开发⽤例的主要⽬的是找到主要参与者。
可以通过下列问题来帮助分析和发现系统的参与者：谁使⽤这个系统？谁安装这个系统？谁启动这个系统？谁维护这个系统？谁关闭这个系统？哪些系统使⽤这个系统？谁从这个系统获取信息？谁为这个系统提供信息？
◦ ⽰例：
我们以当前准备开发的论坛系统为例，前期获取到如下⽤⼾需求：
▪ 注册登录
▪ 帖⼦列表, 发布帖⼦, 删除帖⼦, 回复帖⼦等功能.
▪ ⽀持个⼈主⻚的展⽰/编辑, ⽀持头像上传.
▪ ⽀持帖⼦按版块分类.
▪ ⽀持发布图⽚表情
▪ ⽀持站内私信
▪ 管理员可以添加/删除/修改版块
▪ 管理员可以管理所有帖⼦
综合以上需求描述，可以明显的提到到两个参与者，⼀个是管理员，⼀个是普通⽤⼾。
合并需求获得⽤例
将参与者都找到之后，接下来就要仔细检查参与者，为每个参与者确定⽤例。
⾸先，要将获取到的需求分配给参与者，⽐如，普通⽤⼾可以进⾏注册，登录，编辑个⼈信息，发贴⼦，修改⾃⼰发的贴⼦，发站内信等等，管理员不仅可以进⾏普通⽤⼾的操作还可以进⾏ 版块管理等等。
其次，进⾏需求合并操作，并产⽣⽤例，⽐如对于帖⼦来说，有发布帖⼦，修改帖⼦，删除帖 ⼦，在这⾥合并为操作帖⼦。注：⽤例并不需要包括具体的操作流程(事件流)，事件流将在细化⽤ 例描述中体现。
然后，将识别到的参与者和合并⽣成的⽤例通过⽤例图的形式表⽰出来，⾄此以获得⽤例模型 的框架。如下图所⽰：
细化⽤例描述
⽤例描述可以迭代完成，先对⼀些重要的⽤例编制相对细致的描述，对于那些不重要的⽤例可以留待以后再补充完成，⽤例描述通常包括⽤例名称、简要说明、事件流、⾮功能需求、前置和后置条件、扩展点、优先级。
以操作帖⼦⽤例中的发布帖⼦为例，有如下描述：
- ⽤例名称
发布帖⼦
- 简要说明 ⽤⼾发布新帖，同时增加对应版块帖⼦数量
- 事件流
- ⽤⼾向系统发出发布新贴请求
- 系统展⽰编辑新帖界⾯
- ⽤⼾选择对应的版块类别，写⼊帖⼦标题与正⽂，并提交
- 系统检查版块类别、标题、正⽂是否有效
- 系统将所输⼊的信息存储建档，帖⼦发布成功
- 备选事件流
无
- ⾮功能需求
⽆特殊要求
- 前置条件 ⽤⼾必须登录系统进⾏权限校验
- 后置条件 修改对应版块下帖⼦的数量
- 扩展点 ⽆
- 优先级 最⾼(满意度5，不满意度5)
针对以上⽤例细化描述⽰例可知，⽤⼾发贴前要对登录状态进⾏检查，发贴操作中包含⾝份检
验，⾝份检查在其他操作中也都会涉及，所以我们抽象出⼀个⾝份检验的⽤例，使⽤⽤例图描述⽤
例之间的关系如下所⽰：
定义概念类
概念类：模型中可以代表事物与概念的对象。
OOA的主要任务就是找到系统中的对象和类，这些类将反映到OOD中的软件类和OOP中具体的实现类。
发现类的⽅式有很多种，其中应⽤最⼴泛的是名词短语法，具体步骤如下：
▪ 阅读和理解需求⽂档或⽤例描述
▪ 筛选出名词或名词短语，建⽴初始类清单(候选类)
▪ 将候选类分为三类：分别是显⽽易⻅的类，明显⽆意义的类和不确定类别的类
▪ 舍弃明显⽆意义类别的类
▪ ⼩组讨论不确定类别的类，直到把他们合并或调整到其他两个类别。
根据4.2.4⼩节，发布帖⼦⽤例的事件流，可以获取到候选概念类的清单，如下
经过简单分析：“版块类别” 和 “版块帖⼦数量” 都可以归结到 “版块” 类，做为 “版块” 类的属性；“帖⼦标题” 和 “帖⼦正⽂” 都可以归结到 “帖⼦” 类，做为 “帖⼦” 类的属性；“权限” 可以归结到 “⽤⼾”类，做为“⽤⼾”类的属性。⾄此，针对发布帖⼦这个⽤例，就确定了三个类，分别是：⽤⼾、版块、帖⼦。
确定类之间的关系
当完成了类的寻找⼯作之后，就是理清这些类之间的关系，类之间的关系有：关联、依赖、泛化、聚合、组合和实现，他们在UML中的表⽰⽅式如下：
◦ 关联关系：提供不同类的对象之间的结构关系，⽽不是类与类之间的关系，两个对象之间⼀般 以动词连接，⽐如，⽤⼾-发布-帖⼦；可以⽤⼀个箭头连接，表⽰关联关系对象可以从⼀个端得 到另⼀端对象，如果没有箭头，认为是⼀个双向关系或是⼀个未定义的关联；
◦ 依赖关系：两个类A 和 B，如果B变化可能会引起A的变化，则称类A依赖与B，⽐如，⼀个类是 另⼀个类的数据成员，⼀个类是另⼀个类的某个操作的参数等；
◦ 聚合关系：共享聚集关系通常简称为聚合关系，他表⽰了类之间整体与部分的关系，“部分”可以属于不同的“整体”，“部分”与“整体”的⽣命周期可以不同，⽐如，汽⻋和⻋轮就是聚合关系，⼀个汽有⼀多个轮⼦，汽⻋坏了，轮⼦还可以⽤，轮了坏了可以再换⼀个；
◦ 组合关系：组合聚集关系通常简称为组合关系，他也表⽰了类之间整体与部分的关系，与聚合 关系的区别在于，组合关系中的“部分”只能属于⼀个“整体”，“部分”与“整体”的⽣命周期相同，⽐如：⼀个公司有多个部⻔，他们之间就是组合关系，公司⼀旦倒闭，部分也就不 存在了；
◦ 实现关系：描述的是类和接⼝之间的关系，⼀个类可以实现接⼝中声明的⽅法；
◦ 泛化关系：描述的是⽗类与⼦类之间的关系，继承关系是泛化关系的反关系，也就是说⼦类继 承了⽗类，⽽⽗类是⼦类的泛化。
对于⽤⼾发布帖⼦的⽤例，在确定类与类之间关系之后，可以⽤UML的类图把这些关系记录下 来，如下图所⽰：⽤⼾发布帖⼦，帖⼦聚合成版块
为类添加职责
在找到概念类并且理清了他们之间的关系后，就可为类添加职责，主要包括两⽅⾯内容：
▪ 类所维护的知识，即成员变量或属性
• 注意要保持属性的简单性，即：只定义与系统责任和⽬标相关的属性；使⽤简单数据类
型定义；不为类关联定义属性。
▪ 类能够执⾏的⾏为，即成员⽅法或责任
• 可以根据动词来判断，再进⾏筛选，与识别类的过程类似。
这个阶段只找出⼀些主要的、明显、与业务规则相关的部分，切切忌在这个阶段不断地细化
根据分析得出的类的职责，⽤类图表⽰如下：
建⽴交互图
多个对象的⾏为通常采⽤交互图来表⽰，UML中最常⽤的是顺序图，⼏乎可以⽤在任何系统的场景。
顺序图的基本元素有对象、参与者、⽣命线、激活框、消息和消息线，其中消息是顺序图的灵魂。以⽤⼾登录过程为例，使⽤顺序图描述如下：
软件需求规格说明书
通过识别参与者、合并需求获取⽤例、细化⽤例描述、定义概念类、确定类之间的关系、为类添加职责、建⽴交互图等步骤，已经完成了需求的定义，并把现实世界中的事物抽象成了⾯向对象中的 类，同时也确定了系统的主要功能和范围，上述的⼯作是编写软件需求规格说明书的基础，只要这些 需求汇总起来就形成了软件需求规格说明书中的需求部分。
