软件体系结构2

软件体系结构概述

软件体系结构包括构件(Component)、连接件(Connector)和约束(Constraint)或配置(Configuration)三大要素。

软件需求与架构

需求是指明必须实现什么规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。

与客户打交道的主要目的是：一是获取需求，而是签订合同

软件需求流程

需求的分类：业务需求，用户需求，系统需求，功能需求，非功能需求，设计约束

质量属性：

开发期质量:可扩展性，可复用性，可维护性等；

运行期质量：正确性，健壮性，性能，可靠性，容错性，易用性，安全性，可移植性，兼容性。

需求工程结构图

开发者对待需求工程的态度可分"被动型"、"主动型"和"领先型"三种。

获取需求

需求从哪里来:人，物，系统

获取需求的方法：面谈，问卷，会议…

面谈问题基本上可以分为两种类型:开放式问题和封闭式问题

面谈结构：金子塔型，漏斗型，菱形

用例描述了用户和系统之间的交互

用例模型描述全部的系统功能性行为

二维需求矩阵

约束需求：业务环境因素+使用环境因素+构建环境因素+技术环境因素

ER图中包含三个图形符号：实体，属性，联系

需求分析的主要成果：软件需求规格说明书（Software Requirement Specification, SRS）

需求确认包含两个重要工作："需求评审"和"需求承若"

需求跟踪的目的是建立与维护"需求-设计-编程-测试"之间的一致性。

需求跟踪有两种方式：正向跟踪和逆向跟踪

正向跟踪和逆向跟踪和称为双向跟踪。

跟踪举证

源跟踪举证（需求与需求来源）

功能跟踪矩阵（需求与功能）

依赖跟踪矩阵（一个需求与另一个需求）

UML

UML模型元素

模型元素包括事物以及事物与事物之间的联系

每一个模型元素都有一个与之相对应得图形元素

通用机制

额外的注释，修饰和语意等

包括规格说明，修饰，公共分类和扩展机制四种

UML统一建模语言

用例建模(Use Case Modeling)是使用用例的方法来描述系统的功能需求的过程。

用例建模主要包括以下两部分内容：

用例图

用例描述文档

执行者：在系统之外，透过系统边界与系统进行有意义交互的任何事物。

引入执行者的目的：帮助确定系统边界。

用例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。

对象状态的描述：状态图

工作流程的描述：活动图

交互次序的描述：顺序图

状态图用初始状态（Initial State）表示对象创建时的状态，每一个状态图一般只有一个初始状态，用实心的圆点表示。

每一个状态图可能有多个终止状态（Final State），用一个实心圆外加一个圆圈表示。

状态图中可有多个状态框，每个状态框中有两格：上格放置状态名称，下格说明处于该状态时，系统或对象要进行的活动（Action）。

从一个状态到另一个状态之间的连线称为转移（Transition）。状态之间的过渡事件（Event）对应对象的动作或活动（Action）。事件有可能在特定的条件下发生，在UML中这样的条件称为守护条件（Guard Condition），发生的事件可通过对象的动作（Action）进行处理。状态之间的转移可带有标注，由三部分组成（每一部分都可省略），其语法为：事件名 [条件] / 动作名。

活动图是一种描述工作流的方式，它用来描述采取何种动作、做什么（对象状态改变）、何时发生（动作序列）以及在何处发生（泳道）。

活动图作用:描述业务流程、描述用例路径、描述方法执行流程（程序流程图）

活动图由起始活动(Start Activity)、终止活动(End Activity)、活动(Activity)、转移(Transition)或流(Flow)、决策(Decision)、守护条件(Condition)、同步条(Synchronization)和泳道(Swimlane)等组成。

顺序图的消息:调用消息、返回消息、自身消息、发送消息、创建消息、销毁消息、同步消息、异步消息

交互片段

alt:多条路径，条件为真时执行。

opt:任选，仅当条件为真时执行。

par:并行，每一片段都并发执行。

loop:循环，片段可多次执行。

critical:临界区，只能有一个线程对它立即执行。

组件图又称为构件图(Component Diagram) 。组件图中通常包括组件、接口，以及各种关系。组件图显示组件以及它们之间的依赖关系，它可以用来显示程序代码如何分解成模块或组件。一般来说，组件就是一个实际文件，可以有以下几种类型：

源代码组件：一个源代码文件或者与一个包对应的若干个源代码文件。