当前课程知识点：面向对象分析与设计 > 架构分析 > 架构分析基本概念 > 架构分析基本概念
同学们 今天 我们介绍架构分析的第一部分
在这一部分里面 我们解释一下架构分析的目的
以及在RUP软件开发过程模型中
什么时候来执行架构分析
我们描述一下 如何来描述架构模式以及分析机制
并且架构模式和分析机制是如何来影响到软件体系架构的
另外我们讲一下
在架构分析过程中有哪些主要的考虑 或者说一些架构分析的原则
最后呢我们要介绍一下在面向对象中我们如何来描述架构分析
比如说架构的层 它们的关系、关键概念和分析机制等等
这张图是我们整个RUP软件开发过程的过程模型图
我们可以看到在分析阶段我们所执行的第一个活动就是架构分析
就是说定义初始的软件体系架构
架构分析活动是由架构师来负责完成的
我们在前面讲
软件体系架构定义软件系统最重要、最核心、最基本的一些设计决策
所以架构师在分析阶段首先要定义软件的体系架构
以此为基础
作为后续软件分析、设计一个最重要最基本的约束
在架构分析里面
它的主要输入有哪一些呢
我们来看一下
我们知道呢
软件的分析设计是以需求
是它之前的活动
在架构分析里面
它最重要的输入就是需求活动的输出
需求活动的输出主要有这么几个
第一个是用例模型
我们知道在用例模型里面描述了系统的功能需求
它是我们架构分析活动非常重要的输入
第二个是附加规格说明书
附加规格说明书描述了系统的非功能性需求
比如像性能、安全性、可靠性等等
那么这些非功能性需求对我们架构设计有着非常重要非常大的影响
第三个就是术语表
术语表里面定义了整个系统里面主要的常用的基本概念
除此以外我们的输入还包括
第一个就是软件项目开发指南
我们所有的软件分析设计活动
都必须在项目指南的约束和规范下进行
另外，我们在架构分析设计时
整个软件体系架构分析设计
可能参考到其他的已有的体系架构
参考架构也是我们架构分析设计的一个重要输入
另外，我们在架构分析设计活动里面
我们还有一个非常重要的叫前景文档
什么叫前景文档
我们知道我们的架构设计要满足用户的需求
在需求分析阶段
我们只是定义了整个系统当前的用户需求
但是，用户的业务可能还有变化
比如一个企业
当前用户提到的需求是
我的并发用户数是1000个
通过前景分析，可能过了三年以后
企业的用户规模可能会急剧的膨胀
它的并发用户数可能会到10000个
所以在前景分析里面要对用户的业务
对整个系统的前景做一定的预测
这样，我们在架构设计的时候
我们的架构应该具有较好的扩展性
也就是说，我们的架构设计在能够满足
符合当前用户需求的基础之上
能够提供有效的、良好的扩展性
能够面对未来的用户需求变化
能够很快很方便的进行扩展
来满足它
那么，架构分析的输出主要有这么几个
它的输出活动最重要的软件体系架构文档
在软件体系架构文档里面
定义了我们所设计的软件系统体系架构
另外，在架构分析设计过程中
我们不是说只给出了设计
我们还要描述架构是怎么实现的
所以对应的还有它的初始设计模型
部署模型等等
除此之外我们看到
设计模型和架构文档是双向箭头
那就表示我们的架构设计不是一次做完的
是迭代的
在第二次或者后续的修改过程中
它以之前为输入
进行迭代的修改、精化和完善
下面介绍一下架构分析设计里面的一些基本概念
在面向对象过程中
我们要描述软件体系架构
我们采用的是一种“4+1”视图
其中最重要最核心的
是中间这个用例视图
用例视图它主要从功能角度来描述
也就是说
在用例视图里面
我们描述的是整个系统的功能架构
我们可以看到
为什么把它画在中间
系统的其他四个视图
都要以它为核心
或者说基于它来设计
在往上，这个我们把它称为逻辑视图
逻辑视图它描述了系统的结构
也就是说
描述了整个系统结构里面
有多少个组成元素
以及这些元素的接口
它们相互之间的关系
逻辑视图描述的是整个系统的静态结构
下面这个我们称之为进程视图
我们知道软件在运行过程中
软件表现，软件形态就转化为
进程 线程
所以进程视图就描述了软件在运行过程中
系统中有多少个进程
有多少个线程
以及进程和线程之间的关系
比如说进程会创建它的子进程
以及它们之间的同步 互斥
这些关系都把它定义在进程视图里面
进程视图实际上描述的是整个系统的运行态架构
它更体现的是系统的性能 可扩展性 吞吐量这样一些特性
第三个视图我们称之为实现视图
实现视图它是用来在 软件开发完成后
对软件进行组织和管理的
它描述软件开发完成以后
软件各种程序文件 头文件 配置文件 库文件等等
所以，实现视图对于程序员来讲最为关注的
最后一个我们称之为部署视图
部署视图描述的是软件开发交付给用户的时候
如何把软件部署安装在用户的计算机 服务器等等设备上去
所以部署视图对于系统工程师非常关注
它描述了整个系统的拓扑 安装
不同节点之间的通信关系等等
在UML里面没有专门描述软件系统架构的
所以我们一般用包来代表一个组件
或者说一个子系统
来定义软件系统架构
那么什么是包
在UML里面
在面向对象里面
我们把包定义成一种元素的分组机制
比如说
我们把一些设计模型
通过包把它分成若干个组
所以在包里面
它可以包含其他的模型元素
比如说 前面讲的类可以放在包里面
而且包还可以包含它自身
一个包里面内部可能有其它子包
可以嵌套的进行包含
包在开发阶段可以用作对模型的组织
同时在配置管理阶段
也可以以包为单位
对源文件 程序文件进行管理
包之间的关系只有一种
就是依赖关系
包之间的依赖关系反应
一个包需依赖于 需要使用到另外一个包
所提供的服务
进一步反过来说
如果说
像图上这个例子
客户端这个包依赖于供应者这个包
换句话讲
对供应者这个包的修改变更
可能就会引起客户端这个包的变更修改
其实我们介绍到
包的依赖关系实际上是
包里面的某一个元素它可能依赖于后面这个包的某一个元素
所以我们说这两个包之间有依赖关系
有了依赖关系以后
也就意味着前面这个包
比如在这个图里面
client这个包就丧失了它的独立复用性
换句话讲
我们要复用这个包
必须把它依赖的供应者包一起复用
否者的话，前面Client这个包可能就会出错
有了包的依赖关系之后
我们下面要讲的就是包的循环依赖
比如说最左上的图
我们看到有两个包
A依赖于B
B依赖于A
这是一种最常见的最基本的一种直接循环依赖
循环依赖我们讲它不好
为什么不好
如果两个包之间有循环依赖
我们把B包的内容修改了
因为A依赖于B A相应的需要修改
反过来说 我们把A修改了以后
因为B又依赖于A
那么相应的 B也要进行修改
这样就会在循环依赖的情况下
AB 两个包是紧耦合的
对任何一个包的修改
都可能引入不可预测的 难以发现的错误
除了AB这种直接的循环依赖意外
还有一些更复杂的更隐蔽的循环依赖
比如下面这个情况
A依赖于B B依赖于C C反过来再依赖于A
这也是一种循环依赖
我们讲循环依赖不好
所以在软件设计过程中
我们要避免循环依赖
比如说
以最后介绍的这种ABC三个包之间的循环依赖讲
我们需要把C包里面所依赖的A包内的元素拆解出来
我们定义一个新的包叫A'
这样的话我们就看右边的这个图
A依赖于B B依赖于C
同时把A里面C所需要依赖的那部分单独定义一个A' 的包
这样A依赖于A' C也依赖于C'
这样就把一个循环依赖拆解成单向依赖
好了同学们
今天我们只是介绍了一下架构分析
介绍了架构分析的一些基本概念
后面我们还会在第二讲第三讲里面
详细介绍架构分析的架构模式 分析机制等等
谢谢大家
-软件开发过程中的主要问题和好的解决方法
--软件开发过程中的主要问题和好的解决方法
-RUP软件开发模型的特点
--RUP软件开发模型的特点
-四个基本原则
--四个基本原则
--四个基本原则
-对象和类
--对象和类
--对象和类
-类之间的关系
--类之间的关系
--类之间的关系
-用例模型
--用例模型
--用例模型
-用例之间的关系
--用例之间的关系
--用例之间的关系
-用例建模
--用例建模
--用例建模
-分析与设计概述
--分析与设计概述
--分析与设计概述
-架构分析基本概念
--架构分析基本概念
--架构分析基本概念
-定义模型的高层组织结构
--定义模型的高层组织结构
-确定分析机制、确定关键概念、创建用例实现
--确定分析机制、确定关键概念、创建用例实现
-用例分析概述
--用例分析概述
--用例分析概述作业
-控制类
--控制类
--控制类
-用例行为和类的关系
--用例行为与类的关系
-识别设计元素概述
--识别设计元素概述
--识别设计元素概述
-识别子系统及接口
--识别子系统和接口
--识别子系统及接口
-描述运行态软件体系架构
--描述运行态软件体系架构
-描述分布式系统架构概述
--描述分布式系统架构概述
-用例设计描述
--用例设计描述
--用例设计描述
-子系统设计概述
--子系统设计概述
--子系统设计概述
-创建初始设计类、定义类操作方法
--创建初始设计类、定义类操作方法
-定义类状态
--定义类状态
--定义类状态
-定义类之间的依赖关系、关联关系以及多重性设计
--定义类之间的依赖关系、关联关系以及多重性设计
-定义类的泛化关系、解决用例冲突、非功能性需求
--定义类的泛化关系、解决用例冲突、非功能性需求
