软件工程小结

软件人才职业发展道路：技术+管理

思想：开源节流
过程：扩展的ICONIX过程（介于RUP和XP之间，适用于大中小型软件项目）
方法：MDA、用例驱动的面向对象的分析与设计，DDD
MDA-模型驱动架构
在MDA中软件开发过程是由软件系统的建模行为驱动的
MDA生命周期和传统生命周期没有大的不同，主要的区 别在于开发过程创建的工件，包括PIM（Platform Independent Model，平台无关模型）、PSM （Platform specific Model，平台相关模型）和代码
PIM是具有高抽象层次、独立任何实现技术的模型。 PIM被转换为一个或多个PSM。PSM是为某种特定实现技 术量身定做。
工具：UML建模语言、EA建模工具
知识：……

利润=需求（怎样好卖）-设计（怎样制造）
软件=程序+数据+相关文档

软件工程：
**1、定义--NATO会议：软件工程是为了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和使用完善的工程原理。
IEEE：软件工程是：①把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件；②研究①中提到的途径。

**2、源于软件危机

**3、目标：
付出较低的开发成本； 达到要求的软件功能； 取得较好的软件性能；开发的软件易于移植； 需要较低的维护费用； 能按时完成开发工作

**4、原则：
抽象 --抽取事物最基本的特性和行为
信息隐蔽 --信息封装，使用与实现分离的原则
模块化 --独立的编程单位（类）
局部化-模块之间具有松散的耦合模块内部具有较强的内聚
确定化-所有概念的表达应是确定的、无歧义性的、规范的
一致性
完备性 -可以完全实现系统所要求功能的程度
可验证性-需要对系统自顶向下、逐层分解
使用一致性、完备性和可验证性的原则可以帮助人们实现一个正确的系统

**5、基本原理：
按软件生存期分阶段制定计划并认真实施
坚持进行阶段评审
坚持严格的产品控制
使用现代程序设计技术
明确责任
用人少而精
不断改进开发过程

**6、三要素：工具+方法+过程
软件工程=技术+管理
CASE（计算机辅助软件工程）集成了软件、硬件和一个存放开发过程信息的软件工程数据库，形成了一个软件工程环境

**7、方法学（通常把在软件生命周期全过程中使用的一整套技术方法的集合统称为方法学）
传统方法学（结构化）
面向对象方法学

UML面向对象的分析设计领域里的唯一标准，也是国际通用标准

软件生命周期：
定义（问题定义，可行性研究，需求分析）
开发（设计，编码，测试）
维护 （运行）

软件开发过程模型：
1.瀑布

模型：需求明确，不适应需求经常变化
2.增量模型：分而治之
3.快速原型模型：探索型、实验型、演化型（克服瀑布模型 的缺点）
4.螺旋模型：引入了其他模型不具备的风险分析
5.统一过程模型（RUP）：
4阶段：　
初始阶段-里程碑：生命周期目标里程碑
细化阶段-里程碑：生命周期结构里程碑
构建阶段-里程碑：初始功能里程碑
交付阶段-里程碑：产品发布里程碑。
9工作流：6核心过程工作流（商业建模，需求，分析和设 计，实现，测试，部署）3核心支持工作流（配置和变更 管理，项目管理，环境）

6.敏捷过程模型：
四条基本价值观:
个体和交互胜过过程和工具
可以工作的软件胜过面面俱到的文档
客户合作胜过全同谈判
响应变化胜过遵循计划
典型的敏捷过程模型
XP （Extreme Programming）极限编程
FDD（特性驱动开发）
Scrum
敏捷的统一过程（AUP）

7.ICONIX过程模型：
1-愿景[Vision]：所向往的前景。
1.1价值（伟大的愿景成就伟大的事业）
软件项目愿景意义-回答“为什么开发这个系统”的问题

1.2获取软件项目愿景的方法与步骤：
第一步：找到软件项目的“老大”；
要点：老大是买方；系统要改善的组织； 把产品当项目—定位具体的组织（人群）；
老大就是要改善的组织中最有权力的干系人
第二步：得到“老大”对项目的期望（愿景）；
软件项目的愿景是“老大”愿意掏钱开发这个系统的 目的。
第三步：描述出愿景的度量指标；
不是做具体的事，是改善组织的指标

1.3愿景以外还需考虑：
1.3.1-干系人分析
第一步。识别全部项目潜在干系人及其相关信息
第二步。识别每个干系人可能产生的影响或提供的支持 ，并把他们分类，以便制定管理策略
第三步。评估关键干系人对不同情况可能做出的反应或 应对，以便策划如何对他们施加影响，提高他们的支 持和减轻他们的潜在负面影响
1.3.2-投入（愿意花多少钱，允许多少时间。）
1.3.3-风险
1.3.4-可行性
可行性研究必须从系统总体出发，对技术、经济、财务 、商业以至环境保护、法律等多个方面进行分析和论证 ，以确定建设项目是否可行，为正确进行投资决策提供 科学依据

2-业务建模（属于MDA的PIM阶段）下阶段不需要“老大”
（业务对象和业务用例）

2.1业务建模的意义：
业务建模要求我们把视角从系统转向组织，站在客户角度 看问题，以达到清晰准确地“知彼”。
1）明确为谁服务--找准客户，切记不是在为自己做系统
2）要改进的

组织是什么现状--有什么痛处和不足；
3）如何改进--新系统的价值就是解决客户痛处、改良客 户不足，这才是客户愿意掏腰包的动力

通俗讲业务建模就是把系统放在组织中来看。
组织[Organisation] ——为了实现既定的目标，按一 定规则和程序而设置的多层次岗位及其有相应人员隶属 关系的权责角色结构。例如政府、企业等。
业务[Business]——组织的本行业本职工作。例如医院的 挂号、急诊；银行的储蓄、贷款等。
业务建模[ Business Modeling ]——是以软件模型方式 描述企业管理和业务所涉及的对象和要素、以及它们 的属性、行为和彼此关系。包括对业务组织建模，对 业务流程建模，改进业务流程等方面

2.2业务建模的目的：从组织的角度来定位系统的价值。
业务建模=组织建模

2.3业务建模的步骤：
1）明确我们为谁服务（选定愿景要改进的组织）。
业务组织跟老大的职权范围有关；
业务组织要结合系统愿景；
总之-画一个圈，把大多数责任可能被（部分/全部） 替换的系统（人肉系统/电脑系统）包在里面。

2）了解组织现状（业务用例图、现状业务序列图）

从外部看：组织是价值的集合，用业务用例图来建模

************** 业务用例图：****************
（1）业务组织
（2）业务执行者[Business Actor]
在业务组织之外，与其交互，享受其价值的人或组织
（3）业务用例[Business Use Case]
业务组织为业务执行者提供的价值
业务用例代表组织的本质价值，很难变化，改变的是 业务用例的实现。
业务用例刷新了业务流程的概念。
找业务用例两条路线：
1）从业务执行者开始
2）观察组织的内部活动
以简明扼要的文字对每个业务用例进行描述，通常的 格式是：业务执行者通过业务组织的某些工作，达到 固定目的。
例如取款用例的简述为：银行客户于财神银行营业时 间，到财神银行的营业厅，由银行柜员协助办理取款 业务。

从内部看：组织是系统的集合(人是一种智能系统)， 用业务序列图来建模（序列图以面向对象的思想 来看业务流程）

*************业务序列图**************
业务序列图详细描述业务执行者、业务工人、业务实 体之间如何交互（调用消息，返回消息），以完成某个 业务用例的实现流程

业务工人[Business worker]-位于业务组织内部，负责 业务流程中某些工作的人员
业务实体[Business Entity]-在业务用例的实现流程中 ，

业务工人所使用的“系统”

1识别业务对象：业务执行者、业务工人、业务实体；
2确定业务对象间的职责、协作及交互顺序,绘制业务序 列图。

常用分支：loop-循环；alt-条件分支；opt-可选
消息的名字-代表责任和目的
消息的方向-责任的委托

3）我们如何改进（改进业务序列图）。
了解业务组织现状的目的——发现流程中的改进点：
信息自动流转
封装复杂业务逻辑
职责转移
访问和操作业务对象
其他……

1将新系统作为一个业务实体；
2将其引入组织现有业务流程；
3查看其可以改进的流程；
4评估改进结果。
意义：通过改进业务序列，可以提前模拟出新系统的出 现，将对组织现行的业务流程造成哪些影响，可以提前 评估新系统的可行性或提前进行相应的准备工作，实现安 全平稳的组织改进。


2.4如何获取业务建模所需的信息。
选定组织：老大和他的愿景。
组织业务现状：业务专家的介绍。
组织业务改进：
老大的痛处和愿景；
业务专家的抱怨；
需求分析师的经验和智慧

2.5业务建模结果复核。（签字确认进入需求分析阶段）

3-需求分析(需求分析指的是在建立一个新的或改变一个现 存的电脑系统时描写新系统的目的、范围、定义和功能时 所要做的所有的工作)下阶段不需要“用户”
（域模型，系统执行者，系统用例）

3.1域建模
意义：
为项目创建一个术语表。确保项目中的每个人都 能以清晰一致的术语来理解和交流问题领域。
域建模比普通的项目术语表优良的地方体现在： 以图示化的方式清晰地显示出不同术语间的关系。
域模型图将通过不断修正完善逐步演化为最终的静 态类图
步骤：
Step 1仔细阅读需求文档，提取出名词和名词短语
Step 2排除列表中重复、相似的术语
Step 3排除超出系统范围的术语
Step 4画出第一版域模型图
Step 5整理第一版域模型，确定域模型之间的关系
原则：
1.不要花费太多的时间纠缠在最初的域建模工作上
2.不要把域模型错误地认为是数据模型
3.在用例分析前做域建模，以避免命名混淆
4.不要指望最终的类视图和域模型图完全匹配
5.不要把与界面相关的类加入域模型中

3.2系统用例建模

业务用例:顾客与企业组织的交互.
系统用例:用户与信息系统的交互.

比较业务建模：
业务建模的目的是把视角从系统转向组织，站在客户角度 看问题。
业务用例是对组织为外部业务执行者提

供的价值的建模。
现状业务序列图是对组织价值内部实现流程（业务工人与 业务实体的协作）的建模
改进业务序列图是对新系统为组织提供的改良的建模

意义：
1、系统需求分析的目的是把视角转向新系统，站在最 终用户（及其它干系人）的角度看问题。
2、系统用例是对（新）系统为系统执行者提供的价值 的建模

步骤：
1）.绘制系统用例图（用‘时间’来标示预定的事件）
1.1确定系统边界
1.2识别系统执行者（指向系统的为主执行者，系统 指向的为辅执行者）
1.3识别系统用例
1.4确定用例间的关系
泛化[Generalize]；包含[Include]；扩[Extend]

2）.编写系统用例描述
基本组成：干系人利益（用例是干系人利益的平衡点）
基本路径-以主动语态、“名词-动词-名词 ”格式来书写。
主语只能是执行者或系统。

扩展路径
业务规则
高级 前置条件：开始用例前系统及其环境的状态
后置条件
补充约束……

3）.更新域模型

3.3非功能性需求RUPS
可靠性[Reliability]-系统在一定时间内、在一定条 件下无故障地执行指定功能的能力（7*24h）
可用性[Usability]-一个产品可以被特定的用户在特 定的上下文中，有效、高效并且满意得达成特定目 标的程度。(友好提示)
性能[Performance]-系统实现预期功能的能力的特性 （身份验证时间<1秒）
可支持性[Supportability]-系统在故障解决和系统升 级方面的能力

3.4需求获取的方法
研究文档；问卷调查；访谈；观察；研究竞争对手

4-健壮性分析（不纳入最终文档）

4.1意义：
其一帮助完善用例分析结果；其二完善域模型，做为需 求分析走向系统设计的过度技术；

三种元素：边界类，实体类，控制器类
三种元素的交互规则：
执行者只可以和边界对象通话；
边界对象和控制器可以互相通话（名词<->动词）；
控制器可以和另一个控制器通话（动词<->动词）；
控制器和实体对象可以互相通话（动词<->名词）；

4.2步骤：
1）创建一个空的健壮性图
2）直接将用例文本粘贴到图上
3）从基本路径的第一句话开始画健壮性图。
4）贯串整个用例基本路径，一次一个句子，画执行者 、适当的边界对象和实体对象以及控制器，和各元素 之间的连线
5）将每一个扩展路径画在健壮性图上，并以红色

标示出

5-关键设计 （MDA的PIM）
（类图，序列图）

步骤：
第一步：将现有的域模型直接作为第一版静态类模型；
第二步：基于用例描述和健壮性分析结果，画出每个用例 的序列图；健壮性图中的控制类会转化为方法；
如果转化为控制类，那么就添加到类图中（注意 ：边界类不添加到类图中）；
第三步：整理静态类图和序列图；
第四步：关键设计复核，迭代更新用例图、类图和序列图

类之间的关系：
泛化-实线空三角；
实现-虚线空三角；
依赖-虚线箭头；
关联-实线（组合-实菱形、聚合-空菱形）

6-详细设计（MDA的PSM）
步骤：
1.直接拷贝关键设计的类图过来；
2.客户端类命名以C_为前辍，服务端类以S_为前辍（建议加颜色区分开）；
3.添加日志存储类，并泛化出记录文件和记录数据库两个子类；
4.原来的银行系统接口转到服务器端；
5.在客户端和服务器端分别添加交互的类；