+视图教学课程.pptVIP

系统架构的概念 定义很多，许多架构大师都给架构下过定义，包括Boehm，Woods等。我们这里给出IEEE的定义。 IEEE：架构是以组件、组件之间的关系、组件与环境之间的关系为内容的某一系统的基本组织结构。 理解架构所做的工作并不难，因为“架构关注的是软件的分割与交互”。 架构将系统划分为计算机组件及组件之间的交互。 只是，划分的方式不同。 架构与子系统、框架、类库的区别和联系 3）类库 类库是类的集合，这些类之间可能是相互独立的。应用开发者系统使用类库的人可以直接调用，而不必重写。 框架也是类库的集合，框架中的类并不是孤立的，框架中的类通过业务逻辑“连”在一起，在它们之间建立协作关系。 经典架构模式 所谓“模式”，就是解决相似问题的通用方法，世界是无限的，但模式是有限的。 1）分层 2）MVC 3）微内核 特点：将应用相关部分和通用部分分离，再将通用部分中的基本服务内核和众多扩展服务分离。 优点：可扩展、可移植、适应新技术。 缺点：设计复杂、实现复杂、效率低。 经典案例：OS。 管道过滤器 相当于MVC中控制对象和实体对象形成的一道流水线 架构视图的概念 架构视图的概念 Philippe Kruchten在其著作《Rational统一过程引论》写道：“一个架构视图是对于从某一视角或某一点上看到的系统所作的简化描述，描述中涵盖了系统的某一特定方面，而省略了与此方面无关的实体。 软件架构的每个视图分别关注不同的方面，针对不同的目标和用途。 RUP（Rational Unified Process）中提出4+1视图模型。 用例视图:对系统功能性需求对模，描述系统的行为，揭示 系统“是什么” 逻辑视图:描述系统设计模型，包含与系统结构最重要意义的部分，比如，系统分解成为的子系统，子系统分解成多个类，以及这些元素的职责，关系，操作和属性 进程视图：描述系统分解成线程及进程的过程，描述线程 （进程）通讯模试等 部署视图：描述运行系统的物理硬件（包含网络）配置，说明每个节点的计算机，CPU，操作系统以及它们互联的情况，还要包括进程到节点之间的映射关系。 实施视图：描述系统在构建时的分解后的子系统（包）的情况，特别是包括哪些组成部分由哪些团队开发，以及购入，外包，开发进度等内容。项目经理应该对这个视图最感兴趣。 表1 超市系统案例：理解需求种类的复杂性 非功能需求又可以分为如下三类 约束:要开发出用户满意的软件并不是件容易的事，而全面理解要设计的软件系统所面临的约束可以使你向成功迈进一步。约束性需求既包括企业级的商业考虑（例如项目预算有限），也包括最终用户级的实际情况（例如用户的平均电脑操作水平偏低）；既可能包括具体技术的明确要求（例如要求能在Linux上运行），又可能需要考虑开发团队的真实状况（例如开发人员分散在不同地点）。这些约束性需求当然对架构设计影响很大，比如受到项目预算有限的限制，架构师就不应选择昂贵的技术或中间件等，而考虑到开发人员分散在不同地点，就更应注重软件模块职责划分的合理性、松耦合性等等。 运行期质量属性:这类需求主要指软件系统在运行期间表现出的质量水平。运行期质量属性非常关键，因为它们直接影响着客户对软件系统的满意度，大多数客户也不会接受运行期质量属性拙劣的软件系统。常见的运行期质量属性包括软件系统的易用性、性能、可伸缩性、持续可用性、鲁棒性、安全性等。在我们的超市系统的案例中，用户对高性能提出了具体要求（真正的性能需求应该量化，我们的表1没体现），他们不能容忍金额合计超过 2秒的延时。 开发期质量属性:这类非功能需求中的某些项人们倒是念念不忘，可惜很多人并没有意识到开发期质量属性和 运行期质量属性对架构设计的影响到底有何不同。开发期质量属性是开发人员最为关心的，要达到怎样的目标应根据项目的具体情况而定，而过度设计（overengineering）会花费额外的代价。 一个架构视图是对于从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了于此方面无关的实体。 逻辑视图：当采用面向对象的设计方法时，逻辑视图即对 象模型。* 开发视图：描述软件在开发环境下的静态组织。* 处理视图：描述系统的并发和同步方面的设计。* 物理视图：描述软件如何映射到硬件，反映系统在分布方 面的设计 逻辑视图。逻辑视图关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的“辅助功能模块”；它们可能是逻辑层、功能模块等。 开发视图。开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及