软件工程
软件生命周期
软件的生命周期又称为软件的生存周期或系统开发生命周期，是指从软件的产生直到报废的整个过程，它包括问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级与报废等阶段。每一个阶段都有确定的任务，并产生一定规格的文档(资料),提交给下一个周期作为继续工作的依据。
1.问题的定义：用户需要计算机解决什么样的问题？
2.可行性分析：用户需要计算机解决的问题是否可行(市场可行性需求、技术可行性)
3.需求分析：对用户问题的详细分析，需要对问题进行最大模块划分，自顶向下，逐步细化。细化的程度(将问题细化到可以设计时停止)
4.设计(设计什么样的接口、设计什么样的功能，使用什么样的技术实现)
5.编码：依据需求与设计的文档进行开发
6.测试：验证是否已经解决用户提出的问题(单元测试、功能测试、继承测试、性能测试)
7.维护(修改性维护、完善性维护、预防性维护)
开发模型
瀑布模型
开发的阶段是循序的执行，从系统需求分析开始到产品的发布维护，每一个阶段都会产生循环反馈(重复执行)，如果在某个阶段出现问题，需要从上一个阶段甚至更早的阶段解决排查问题。
使用场合：需求明确，解决方案明确，常在一些中小型项目中使用。
原型模型
该模型强调：开发阶段围绕着原型进行，逐步求精对原型进行修改优化。
使用场合：前期需求不确定，采用原型模型。
增量模型
相当于前两种模型的结合，每一次增量经过开发的每一个阶段(瀑布模型经过的所有阶段)；每一次增量对功能进行完善(原型模型的逐步求精)
使用场合：大型项目，需求不明确
软件工程开发方法
需求分析
什么是需求？
用户对目标软件系统在功能、行为、性能、设计约束等方面的期望
什么叫需求分析?
发现需求、求精、建模和定义需求的过程。
需求分析是在问题定义及可行性分析完成后细化用户对软件的功能和性能的要求，即用户希望软件能做什么事情，完成什么样的功能，达到什么性能。
需求分析是软件开发的开端，我们设计的产品存在不完整性、不正确性大部分原因是需求分析错误所导致的，因此，需求分析是软件声明周期中最重要的过程。
需求分析包括：需求调研、需求描述、需求评审三个阶段。
需求获取
关键问题：对问题空间的理解；人与人之间的通信；不断变化的需求
最终会形成系统的解决方案或目标系统的模型。
需求调研阶段：挖掘用户需求。首先确定目标用户，开发人员和目标用户确定一个用户领域，并定义一个描述问题的系统，用户在这个问题领域和系统下提出的需求，需求类型包括：功能需求、质量需求、用户体验需求等。
获取需求的方式
1.与客户交谈，向用户提问题
2.参观用户工作流程
3.使用问卷方式
4.与同行业专家交流
5.分析已经存在的软件产品、提取需求
6.从网络获取相关行业的信息
需求规格说明书
软件开发过程中一份重要的文档
目的是：便于用户、开发人员进行理解与交流；反映出用户问题的结构，可以作为软件开发工作的基础和依据；作为确认测试和验收的依据；为成本估算和编制计划进度提供基础；软件不断改进的基础
需求规格说明书格式
项目概述
1.产品介绍
2.产品范围
3.用户群体及特色
4.运行环境
5.假设、依赖、约束
产品的功能需求
1.整体业务流程图/用例图
2.功能性需求分类
3.信息(前端和后端)
4.用户(功能需求)
产品的非功能需求
1.用户界面需求
2.性能需求
3.产品质量需求
4.其他需求
辅助工具
项目的架构图：使用visio绘制，使用prowerdesigner绘制用例图
需求分析方法
面向数据流的分析方法(结构化分析方法)
数据流图、数据字典、判定树、判定表
自顶向下、逐层分解、建立系统的处理流程，以数据流图和数据字典为主要工具，建立系统的逻辑模型
数据流图(DFD)
数据流图示例：
数据字典(DD)
面向对象的分析方法(有待学习)
用例建模
关联干系人需要以及软件需求；
确认与系统交互的人或对象
定义系统边界
捕捉和传达系统的理想行为(用例)
用例模型的表示
文本描述、图形表示
参与者(Actor)：与系统交互的人或者外部系统
用例(User case):系统参与者提供的有价值的服务功能，使用椭圆形表示，命名方式为动宾结构。
关联(Association):用例图中用例与参与者之间的交互关系,用直线或带箭头的直线表示
参与者
1.与系统交互的人
2.与系统交互的硬件组件
3.或者其他的外部系统
4.关注的重点是所承担的”角色”
5.参与者的命名要明确定义其角色
用例：
1.定义了一个参与者要用到的系统功能
2.描述系统为实现参与者价值所开展的行为序列
3.对参与者与系统之间的交互活动进行建模
4.从特定的用户角度出发，是完整的，实现特定用户价值的事件流
交互——关联(Association)
参与者与用例之间的交互通道
用一条直线表示交互——关联
有箭头的关联指出是谁发起的交互
没有箭头的表示双方都可以发起交互
构建用例模型
步骤
第一步：找到所有的参与者和用例：识别出参与者并做简单的描述；识别出用例并做简单的介绍
第二步：给用例事件流程划分重要等级；按照重要程度排序详细描述事件的流程
Use Case模型的建立步骤：
1.找出系统外部的参与者和外部系统，确定系统的边界和范围
2.确定每一个参与者所期望的系统行为
3.把这些系统行为命名为Use Case
4.使用泛化、包含、扩展等关系处理系统行为的公共或变更部分；
5.编制每一个Use Case的脚本
6.绘制Use Case图
7.区分主事件流和异常情况的事件流，可以把表示异常的事件流作为单独的Use Case处理
8.细化Use Case图，解决Use Case间的重复与冲突
建模过程的检查项
1.用例建模是为了表示系统的行为。通过建模来理解系统的功能。
2.应该识别出所有的用例，用来表达所有的需求
3.系统的任何一个特性都可以找到对应的用例
4.用例模型并不包含多余的行为；所有的用例可以追溯到系统的功能性需求作为验证
5.去掉所有的CRUD类的用例 统称为维护XXX信息
创建(Create)、查找(Retrive)、更新(Update)、删除(Delete)
用例的生命周期
用例识别(Discovered)——用例简述(Briefly Described)——用例提纲(Outlined)——用例详细规约(Fully Described)
用例描述模板：
UC_id:用例名
描述:对该用例的一句或两句的描述
参与者：参与该用例的参与者
包含：该用例所包含的用例，以及包含它的用例
扩展：该用例可以扩展的用例，以及扩展它的用例
泛化：若该用例的子用例和父用例
前置条件：启动此用例所必须具备的条件
细节：该用例的细节
后置条件：在该用例结束时确保成立的条件
例外：在该用例的执行的过程中可能引起的例外
限制：在应用中可能出现的任何限制
注释：提供可能对该用例是重要的任何附加信息
功能分解
用例定义不是功能分解
功能分解:将问题分解为粒度小，独立的部分，不同的模块协同工作，体现系统的功能。通常存在没有意义的功能分解。
功能分解与用例描述
对于用例分解过于细化，产生细小的用例
用例过多且没有实际价值的用例
通过底层操作进行命名
不能够理解整体模型
设计
根据软件需求说明书进行设计，设计系统整体架构、系统外部和内部接口、实现算法和核心代码编写等，分为两个阶段: 总体设计(概要设计)和详细设计
概要设计
概要设计内容：总体结构和各个模块间的关系、系统网络部署结构、核心业务流程、定义系统的外部接口以及模块间的接口。
总体结构与各个模块之间的关系：技术架构与功能架构
技术架构：使用什么样的技术架构
JavaEE使用SSH(struts2+spring+hibernate)或者SSM(spring+springmvc+mybatis)
业务流程图：使用visio对系统流程进行绘制
功能架构： 系统的整体架构功能图绘制，使用visio
接口设计: 定义系统外部接口以及模块间的接口
接口描述的内容、接口功能描述、接口的方向、协议等
详细设计
详细设计的主要任务内容是设计每个模块的类接口、所需的局部数据结构、无理数据模型、页面原型等。
每个接口的类接口：伪代码、描述接口的参数、接口功能
物理数据模型：使用prowerdesigner进行物理模型设计，通过该工具创建表、存储过程等。
