【期末复习】软件工程

结构化分析：数据流图、er图、状态转换图、数据字典

结构化设计：流程图、盒图、pad图、IPO图、判定表、判定树、软件结构图

面向对象分析：用例图、活动图、包图、类图、顺序图、协作图、状态图

面向对象设计：三层架构、构件图、部署图

软件生存周期模型

1)瀑布模型
瀑布模型是把每一个阶段都划分的很独立。
自上而下、相互衔接的固定次序。

2)增量模型

我们通常可以先以某个核心需求作为初始，然后按照瀑布模型的活动组织方式，去完成这个需求。后面如果还有新的需求，可以通过增量的方式，再按照瀑布模型的方式完成增量的开发，从而最终完成所有的用户需求。

而软件的功能实际上是为了实现某种需求，软件的功能可以分解，因此需求也是可以分解的。

分类：增量构造模型、演化提交模型

3)演化模型（原型模型）
定义：是一种有弹性的过程模式，由一些小的开发步组成，每一步需要经历需求分析、设计、实现和验证。

特点：通过迭代，完成最终软件产品的开发。需要快速的迭代，经历从需求到最后测试的过程，形成一个可运行的雏形，给用户反馈。

适用：适用于不能预先确切定义需求的软件项目
验证你的项目的可行性，原型模型是比较适用的
就是在你不确定的需求，甚至当其他阶段比如采用的实现手段、技术不确定的时候，都可以使用原型模型，尽快的开发出一个可运行的版本

上诉三种模型的本质区别：主要在于需求是否明确。瀑布模型是需求十分明确，增量模型是部分明确，原型模型通常是需求不太明确的

4)喷泉模型（生鱼片模型）
迭代、无缝。即软件开发各个阶段中没有明确界限。

5)螺旋模型

从内到外看，每一次迭代都经历了四个象限，旋转了一周，依次获得的原型是概念、需求、设计以及最后的可运行原型产品，产出的是瀑布模型的一个阶段的产品。

而且每一个开发阶段前引入风险分析，每迭代一次，软件开发阶段前进一个层次。每迭代一次，都是瀑布模型的一个阶段的活动，就是说瀑布模型的每一个阶段的活动，螺旋模型都经历了一个周期。

螺旋模型的风险分析实际上是为了商业大型软件的开发，所以螺旋模型也是风险驱动的模型。

面向对象软件过程模型

1）构件集成模型
整个系统模块化
复用构件库中的软件构件

2）统一过程模型
统一过程模型RUP（Rational Unified Process)把软件开发的各个阶段整合在一个统一的框架之中。

统一过程模型是一个二维的软件开发模型

统一过程模型驼峰图：

总结：
1）瀑布模型是一种线性模型，文档驱动的模型。
2）增量模型采用一系列的增量方式开发系统。
3）螺旋模型结合瀑布模型和快速原型，是一种风险驱动的开发模型
4）构件集成模型利用模块化方法将整个系统模块化，复用构件库中的软件构件，通过组合手段提高应用软件系统过程的效率和质量。
5）统一过程模型是以用例驱动的，以架构为中心，迭代和增量的过程。
6）瀑布模型是需求十分明确，增量模型是部分明确，原型模型通常是需求不太明确的

需求分析

1）定义：
是指在开发一个新的或升级一个已有的软件系统时描写新系统的目的、范围、定义和功能时所要做的所有工作。

2）作用：
需求分析是软件开发的工作基础。它将作为后面软件设计活动的基础，同时又是最终软件验收评估的依据。

3）目的：
要求开发人员准确的理解用户需要什么，进行细致的调查分析，将用户的需求陈述转化为完整的需求定义，再转化为相应的软件需求规格说明。

【需求分析最终的目的就是从业务需求、用户需求那里获取到我们项目系统软件开发的需求，即系统到底要做什（what），然后将需求用更精确的，半形式化的方式描述出来，形成需求规约说明书。】

4）分类：
A.业务需求：
从组织机构或客户角度，对系统、产品高层次的目标需求。

B.用户需求：
从使用产品的用户的角度，即用户的目标或用户要求系统必须能完成的任务。

C.功能需求：
从产品本身的角度，即产品要具备怎样的功能，才能满足相应的业务需求和用户需求。

D.非功能需求：
非功能需求包括性能、外部接口、设计约束、质量属性等。

【业务需求和用户需求是用来推导出软件功能需求和软件非功能需求的。】

例子：用户自动寄件
业务建设方：某快递公司
需求描述：目前很多城市的小区都已经有了快递柜，但快递柜主要是用于送件使用，而对于快递公司收件，用得比较少，某快递公司，就希望利用快递柜，来实现用户自助寄件的需求。
业务需求：用户自助寄件，减少人力成本、高效、准确无误。
用户需求：自助寄件，而且简单、易用，高效、快捷。
功能需求:
场景阶段：填单，放件，支付
填单：电子表格方式；
服务定位：发现柜子、导航；
找到空闲柜子：柜子忙闲资源管理
打开柜子：通过扫描、验证码等方式
计量：按体积
支付：提供多种支付方式

5）获取需求的方法：
①自悟 ②交谈 ③观察 ④小组会 ⑤提炼
【会谈技术、调查技术、场景分析技术、快速原型法】

场景分析技术 案例：
场景名：取款
参与者：银行客户
场景描述：
1．插入有效的银行卡；
2．ATM机验证该银行卡；
3．系统要求输入银行卡密码，用户输入密码；
4．系统通过 络向银行内部系统请求验证密码；
5．若验证通过，系统请求选择业务，选择取款；
6．系统要求输入取款金额，比如1000元；
7．系统验证是有足够的现金，并请求验证银行内部服务器处理取款；
8．若处理成功，系统计算钞票数目，并送出现金；
9．用户取走现金；
10．系统打印凭条，用户取走凭条；
11．系统退出银行卡，用户取走银行卡。

快速原型法 案例1：图书馆系统
图书流通管理：负责图书借还工作。
用户：希望快速得到借书，还书服务，能够续借、预约图书，以及查询个人和图书信息。
编目管理员：负责图书的管理、用户管理和处理罚金等
图书借出：管理员完成一次借书过程。
图书归还：管理员完成一次还书过程。
图书预约：用户查询要借的图书，若不能借，可预约该图书。
图书续借：用户可以将图书的归还日期延长一段时间。
图书管理：添加新书。更新图书馆信息，销毁图书。
用户管理：注册新用户，更新用户信息，注销用户。
处理罚金：用户缴纳罚金，系统将罚金数额清零。

快速原型法 案例2：ATM系统
银行客户: 接受系统服务；
银行的代表: 银行间自动柜员机有互惠协议；
支行管理者: 从该系统中获得管理信息；
支行柜台职员: 负责系统日常运转和处理客户意见；
数据库管理者: 负责系统和客户数据库集成；
银行信息安全管理者: 负责保证系统信息安全；
银行市场开发部: 将该系统视为银行市场开拓手段；
硬件和软件工程师: 负责硬件和软件维护及升级。
存款：从ATM机上存钱到指定账户上。
取款：从指定账户上取一定数量的货币。
转账：从一个账户取出一定数量的货币，然后转存到另一个账 上。
查询余额：察看指定账户的余额。
修改密码：修改账户密码。

6）需求规约（又叫 需求规格说明 或 需求规约文档，即 SRS）：
A.概念：需求规约是一种规范，形式化或半形式化的描述了系统的功能，性能，设计约束，数据，验收标准等所有与需求相关的信息。通常以软件需求规格说明书的形式存档。

B.作用：
a.作为软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现；
b.对于项目的其余大多数工作，是一个管理控制点；
c.对于产品的设计，是一个正式的、受控的起始点；
d.是创建产品验收测试计划和用户指南的基础，即基于需求规约一般还会产生另外两个文档—–初始测试计划和用户系统操作描述。

C.软件需求和软件需求规约的区别：软件需求规约即为软件需求的规范化描述。

D.需求分析的一般过程：
采用需求获取技术从用户等人员获取需求，确定功能、性能、设计约束、外部接口、质量属性等，然后选用合适的软件开发方法学（如结构化方法学，面向对象方法学），采用其需求分析方法建立模型（即对需求进行精确建模），然后将编写SRS草案，评审形成最终的SRS，将作为软件设计的基础，作为用户和开发人员之间软件最终验收的标准。

结构化分析

1.定义：一种适用于大型数据处理系统的、面向数据流的需求分析方法。
1）面向数据流的建模方法
数据流图（DFD）-功能域
2）面向数据的建模方法
实体关系图（E-R图）—信息域
3）面向状态的建模方法
状态转换图（STD）-行为域

2.结构化需求分析建模方法：
1）面向数据流的建模方法：数据流图（DFD, Data Flow Diagram）-功能域

A. 建模元素：

C.构建DFD的过程：自顶向下，逐层分解

② 构建0层数据流图 （细化顶层数据流图）
0层数据流图体现系统主体功能及各项功能与外部的接口情况，主体功能体现系统框架。由四部分组成：
◆加工。每个主体功能用一个加工表示。
◆主体功能相关的输入、输出数据流。
◆外部实体。这些外部实体分别通过输入数据流引发各主体功能执行，并接收执行后的输出结果。
◆数据存储。体现主体功能执行后产生的、需要保留在系统内部的结果数据的去处。

数据流图 案例1：
设一个工厂采购部每天需要一张订货 表。
订货的零件数据有：零件编 、名称、数量、价格、供应者等。
零件的入库、出库事务通过计算机终端输入给订货系统。当某零件的库存数少于给定的库存量临界值时，就应该再次订货。
（顶层->0层->1层）

（按层给加工编 ）

（保持父图与子图的平衡

3）面向状态的建模方法：状态转换图（STD）-行为域
（1）状态机建模方法步骤：
①系统状态、行为与事件分析
②构建状态图

（2）状态模型一般采用状态转换图（简称状态图）的标记方法

（3）表示
①状态是可观察的行为模式，用圆角矩形表示。初态用实心圆表示，终态用一对同心圆表示；
②变迁表示状态的转换，用箭头表示；
③事件是引发变迁的消息，用箭头上的标记（事件表达式）表示。
事件表达式的语法如下：
事件说明[守卫条件]/动作表达式
（4）案例：
【例】某汽车停车场欲建立一个信息系统，需求如下：
a．在停车场的入口和出口分别安装一个自动栏杆、一台停车卡打印机、一台读卡器和一个车辆通过传感器。
b．当汽车到达入口时，驾驶员按下停车卡打印机的按钮获取停车卡。当驾驶员拿走停车卡后，系统命令栏杆自动抬起；汽车通过入口后，入口处的传感器通知系统发出命令，栏杆自动放下。
c．在停车场内分布着若干个付款机器。驾驶员将在入口处获取的停车卡插入付款机器，并缴纳停车费。付清停车费之后，将获得一张出场卡，用于离开停车场。
d．当汽车到达出口时，驾驶员将出场卡插入出口处的读卡器。如果这张卡是有效的，系统命令栏杆自动抬起；汽车通过出口后，出口传感器通知系统发出命令，栏杆自动放下。若这张卡是无效的，系统不发出栏杆抬起命令而发出告警信 。
e．系统自动记录停车场内空闲的停车位的数量。若停车场当前没有车位，系统将在入口处显示“车位已满”信息。这时，停车卡打印机将不再出卡，只允许场内汽车出场。

请画出停车场入口护栏的状态图。

结构化设计

1 . 概念: 软件系统设计是把软件需求“变换”为用于构造软件的蓝图。
“输入”是需求分析各种模型元素
“输出”是软件设计模型和表示

2 . 目的: 软件设计的目标是对将要实现的软件系统的体系结构、系统的数据、系统模块间的接口，以及所采用的算法给出详尽的描述。

软件模块化设计的指导思想：分解、抽象、逐步求精、信息隐蔽和模块独立性

3 . 分类:

1. 总体设计，也称为概要设计，软件结构设计，或高层设计。 【 总体设计的一般过程：将DFD变换到初始的MSD，然后根据一些设计原则对MSD进行精化、优化 】
   分析需求规格说明
   模块划分，形成具有预定功能的模块组成结构
   表示出模块间的控制关系
   给出模块之间的接口

（1）主要任务（即 功能模块化）
将系统划分成模块；
决定每个模块的功能；
决定模块的调用关系；
决定模块的接口，即模块间传递的数据。

（2）在概要设计阶段，结构化设计 主要采用 面向数据流的设计方法。
（面向数据流分析（DFA，Data Flow Analysis）的设计是一种结构化的软件体系结构设计方法。）
（这一设计技术是从数据流图（DFD）分析模型映射为软件模块组成结构设计的描述，所以也称为结构化设计（SD，Structured Design）方法。）

（3）三种数据流类型：变换流、事务流、混合流
换流

合流（将事务流和变换流组合出现）

2.2.2 判定树
判定树是判定表的变形，一般情况下它比判定表更直观，且易于理解和使用

2.3语言工具：PDL语言（过程描述语言）

7.软件模块结构图的优化原则
1） 改进软件结构，提高模块独立性
2) 模块规模适中-每页60行语句
3) 深度、宽度、扇入和扇出适中
4) 模块的作用域力争在控制域之内
5) 降低模块接口的复杂性
6) 模块功能应该可以预测

【1. 模块的规模最终还是应该由模块的功能来决定，不违背模块的单一职责原则。一个模块具体多少句这个不定。当然如果过长会影响可读性。
2. 软件模块结构图的形态特征：一般顶层扇出数较高一些，中间层扇出数较低一些，底层扇入数较高一些。当然，也不能过分追求底层扇入数，不能违背模块高内聚特性。】

面向对象分析

1.基础
面向对象分析（OOA，Object-Oriented Analysis）
面向对象设计（OOD）
面向对象实现(OOP)
面向对象测试(OOT)

2.统一建模语言UML
一建模语言（UML，Unified Modeling Language）是一种基于面向对象的可视化建模语言。
ML用丰富的图形符 隐含表示了模型元素的语法，并用这些图形符 组成元模型表达语义，组成模型来描述系统的结构（或称为静态特征）以及行为（或称为动态特征）。
ML的模型元素：
类模型元素用于表示模型中的某个概念，如类、对象、用例、结点、构件、包、接口等；
一类模型元素用于表示模型元素之间相互连接的关系，主要有关联、泛化（表示一般与特殊的关系）、依赖、聚集（表示整体与部分的关系）等。
向对象分析阶段的主要任务是获取用户的需求，并构建系统初步的逻辑模型。

3.用例建模
1）用例图
（1）建模元素
参与者：与系统交互的用户或其他软硬件系统，用小人形表示。
用例：系统中执行的一系列动作，用椭圆表示。
关系：参与者与用例、参与者之间、用例之间的联系。
主题：一组用例描述的系统或子系统，用矩形框表示。
（2）例子

扩展关系（<>）：扩展用例可以在基础用例之上添加新的行为。
箭头方向由扩展用例指向基础用例。

（4）案例1 酒店订房系统
(1)顾客可以选择在线预订，也可以直接去酒店通过前台服务员预订；
(2) 前台服务员可以利用系统直接在前台预订房间；
(3) 不管采用哪种预订方式，都需要在预订时支付相应订金；
(4) 前台预订首选通过现金形式进行订金支付，若现金不足，则只能通过信用卡形式进行订金支付，但是 上预订只能通过信用卡进行支付；
(5) 利用信用卡进行支付时需要和信用卡系统进行通信；
(6) 客房部经理可以随时查看客房预订情况和每日收款情况。
构造该系统的用例模型。

例子：
用例名称：处理一次销售
范围：POS机应用
级别：用户目标
主要参与者：收银员
涉众及其关注点：
收银员：希望能够准确、快速地输入，而且没有支付错误，因为如果少收货款，将从其薪水众扣除。
售货员：希望自动更新销售提成
顾客：希望以最小代价完成购买活动并得到快速服务。希望便捷、清晰地看到所输入的商品项目和价格。希望得到购买凭证，以便退货。
公司：希望准确地记录交易，满足顾客要求。希望确保记录了支付授权服务的支付票据。希望有一定的容错性，即便在某些服务器构件不可用时（如远程信用卡验证），也能够完成销售。希望能够自动、快速地更新帐户和库存信息。
经理：希望能够快速执行超控操作，并易于更正收银员的不当操作。
前置条件：收银员必须经过确认和认证。
成功保证（或后置条件）：存储销售信息，更新帐户和库存信息，记录提成，生成票据，记录支付授权的批准。

2）活动图
（1）基本元素
初始节点和活动终点：实心圆表示初始节点（只有一个），圆圈内加一个实心圆来表示活动终点（可有多个）。
活动节点：表示一个活动。

5.包图

9.状态图
POS机状态图

【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。
聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。
【代码体现】：成员变量
【箭头及指向】：带空心菱形的实心线，菱形指向整体