软件系统分析与体系结构设计

一、软件工程概论

概念

• 软件危机（软件开发和维护过程中遇到的一系列严重的问题）
  • 软件开发成本日益增长
  • 软件开发进度难以控制
  • 软件质量难以保证
  • 软件维护困难

成本，质量难以保证，维护难，开发过程难控制

• *软件危机的原因
  • 软件的复杂性
    • 开发结构的逐渐复杂性
    • 软件技术的发展复杂性
  • 软件的特殊性
  • 人们认识的局限性

围绕软件越来越“复杂”

• *软件工程定义：将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中。

简单的背为将工程化应用在软件中

• 软件生命周期

  • 需求分析
  • 系统设计
  • 系统实现
  • 测试
  • 维护

• *软件系统分析与设计的重要性

  • 需求分析为整个软件打下良好基础
  • 设计阶段为软件的编写打下良好基础
  • 这两个阶段若做好可以从根本上减少软件开发过程的时间和成本
  • 反之，带来的损失是不可估量的

整本书的重要性，肯定要背下来，需求分析打下基础，设计打下基础，做的好有很多好处，做的不好损失太大了

软件工程学的三个核心元素

• 软件开发过程模型

  • 线性模型（瀑布模型）
    • 优点：1.有利于开发人员管理2.有利于使用软件开发工具，提高了效率
    • 缺点：1.开发是线性的，开发结果得到慢，与用户交互少了2.前期的的错误扩散到后期3.无法解决复杂情况
  • 增量模型
    • 优点：1.灵活性高2.需要人员少
    • 缺点：1.需要开发式的体系结构2.退化成边做边改模型，失去整体性
  • 螺旋模型
    • 优点：1.支持用户需求动态变化2.方便用户参与，提高软件适应能力3.方便管理人员及时调整管理决策，降低开发风险
    • 缺点：1.需要丰富的风险评估经验和专业知识2.不适用于合同项目的开发3.过多的迭代造成成本增加，延迟提交时间

• 软件开发方法

  • 结构化方法
  • 面向对象方法
  • 相同点：
    • 都是软件系统的开发方法
    • 在运用分解和抽象原则上的要求是完全一致的。
    • 局部化和重用性设计上的一致。
  • 不同点：
    • 结构化方法是一种面向数据流的开发方法，面向对象方法是一种面向对象的开发方法
    • 处理问题时的出发点不同。前者是一种面向过程的开发方法
    • 处理问题的基本单位和层次逻辑关系不同
    • 数据处理方式与控制程序方式不同
    • 分析设计与编码转换方式不同

• 软件工程工具（泛指软件开发全过程中使用的各种程序系统）

  • 工具
  • 工具接口
  • 用户接口

• *CASE（计算机辅助软件工程）原指支持管理信息系统开发的、由各种计算机辅助软件和工具组成的大型综合性软件开发环境；现已转化为支持整套独立

• *CASE的分类

  1. 事务系统规划工具(Business System Planning Tools)
  2. 项目管理工具(Project Management Tools)
  3. 支撑工具(Support Tools)
  4. 分析与设计工具(Analysis and Design Tools)
  5. 程序设计工具(Programming Tools)
  6. 测试与分析工具(Test and Analysis Tools)
  7. 原型建造工具(Prototyping Tools)
  8. 维护工具(Maintenance Tools)
  9. 框架工具(Frame Tools)

---

二、结构化分析和设计方法

结构化方法的基本思想

• 结构化方法的特点：自顶向下地分析与设计，逐步求精。

• 结构化分析

  • 功能建模
  • 数据建模（数据流图、层次化数据流图）

• 结构化设计

  • 概要设计（软件结构图）
  • 详细设计

• 数据流图

  
  
  

中间的订书组去掉

• 软件结构图

  
  
  
  
  
  

---

三、面向对象分析和设计方法概述

概念

• 面向对象=对象+类+继承+通信

• 面向对象的特点

  • 抽象性
  • 封装性
  • 共享性（共享【数据结构和行为特征】）
    • 同一类中所有实例共享数据结构和行为特征
    • 同一应用中所有实例通过继承共享数据结构和行为特征
    • 不同应用中所有实例通过复用共享数据结构和行为特征

• RUP统一开发过程：核心在于用例驱动；以体系结构为核心；以质量控制和风险管理为目标；迭代的、增量的过程

• RUP的特点

UML统一建模语言

• *UML的意义

1. UML统一了各种方法对不同类型的系统、不同开发阶段以及不同内部概念的不同观点，从而有效的消除了各种建模语言之间不必要的差异。
2. UML建模能力比其它面向对象建模方法更强。它不仅适合于一般系统的开发，而且对并行、分布式系统的建模尤为适宜。
3. 使用UML使硬件组件和软件组件之间将会有更大的透明度。便携性和综合效率将会增加。

• UML视图
  • 用例视图
  • 逻辑视图
  • 构件视图
  • 进程视图
  • 部署视图

• 四种关系
  • 依赖：一个元素的变化将影响到某个元素或向其提供信息
    ------ ➤
  • 关联
    ——➤
  • 泛化（继承）
    ——➣
  • 实现
    ------➣

虚线为依赖，实线为关联（没屁意义），空心箭头的很容易另记。

---

四、需求分析与用例建模

概念

• 需求分析的任务是发现、求精、建模和规格说明的过程。包括
  • 细化在项目开发计划中规定的软件范围
  • 创建所需要的数据模型、功能模型和控制模型
  • 分析可选择的解决方案，并将它们分配到各个软件成分中去
• 需求分析的步骤
  • 问题识别（需求获取）
  • 分析与综合（需求建模）
  • 编制需求分析阶段的文档（需求描述）
  • 验证（需求评审）

就背括号里的步骤了

• 场景和用例：用例：系统执行的完整动作，场景：用例的实例

• 场景的作用

  • 帮助我们验证用例是否能满足客户提出来的需求
  • 驱动测试用例的编写

• 规格说明

  • 用例名称
  • 用例简述
  • 行为者
  • 前置条件
  • 后置条件
  • 基本事件流
  • 备选事件流
  • 异常事件流

用例图后要写，必背

用例建模

• 用例之间的关系（包含、扩展、泛化）

　　a. 关联(Association)
　　表示参与者与用例之间的通信，任何一方都可发送或接受消息。
　　【箭头指向】：指向消息接收方

　　b. 泛化(Inheritance)
　　就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。
　　【箭头指向】：指向父用例

　　c. 包含(Include)
　　包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。
　　【箭头指向】：指向分解出来的功能用例

　　d. 扩展(Extend)
　　扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。
　　【箭头指向】：指向基础用例

　　e. 依赖(Dependency)
　　以上4种关系，是UML定义的标准关系。但VS2010的用例模型图中，添加了依赖关系，用带箭头的虚线表示，表示源用例依赖于目标用例。
　　【箭头指向】：指向被依赖项

• 一个用例图示例：

---

• 关系的使用（这段文字太绕了不看了）
  • 一个用例偶尔使用另一个用例的功能描述时，采用继承关系
  • 两个以上用例重复处理同样的动作，可采用使用关系或包含关系
  • 用例要采用多种控制方式对异常或任选动作进行处理时，采用扩展关系

一个例子

包括可以简单理解成这个用例有什么，比如订购的内容是提供用户信息、付款安排等
扩展就是定购额外做的事情，我理解呢就是这个这个事物本身不一定要，但是在这次建模里有特殊性才附加

案例（一定要看书上两个案例）

• 本人写的只具有参考作用

1. 请根据以下要求画出一个保险业务相关的用例图。
   参保顾客与保险公司业务员签署保险凭单；保险公司业务员统计自己业务范围内的保险金额和参保顾客人数；保险公司业务经理查询统计公司所有保险总金额和参保顾客总人数。

1.先画出顶层用例图

下面针对保险业务处理、统计个人业务、查询统计全公司业务分别进行细化

• 保险业务处理
  • 查看并选择保险业务
  • 签署保险凭证
• 统计个人业务
  • 统计自己参保顾客人数
  • 统计自己业务金额
• 查询统计全公司业务
  • 查看公司总保险人数
  • 查看公司保险总金额

我觉得这样写的太马虎了考试一定多想点方面

2.再画出细化用例图