软件架构.pptx

软件架构.pptx

《软件架构.pptx》由会员分享，可在线阅读，更多相关《软件架构.pptx（17页珍藏版）》请在冰豆网上搜索。

软件架构定义：

软件架构是指在一定的设计原则基础上，从不同角度对组成系统的各部分进行搭配和安排，形成系统的多个结构而组成架构，它包括该系统的各个组件，组件的外部可见属性及组件之间的相互关系。

组件的外部可见属性是指其他组件对该组件所做的假设。

随机谈谈架构的情况软件体系结构是构建计算机软件实践的基础。

与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。

软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。

特别是，很难明确地区分设计和构架：

构架属于设计的一方面，它集中于某些具体的特征。

软件架构的组成详细地说，就是要包括架构元件（ArchitectureComponent）、联结器（Connector）、任务流（TASk-flow）。

所谓架构元素，也就是组成系统的核心砖瓦，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。

（看到架构的两要素：

元件划分和设计决定）软件架构的目标目标：

正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？

一般而言，软件架构设计要达到如下的目标：

可靠性（Reliable）。

软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。

安全性（Secure）。

软件系统所承担的交易的商业价值极高，系统的安全性非常重要。

可扩展性（SCAlable）。

软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。

只有这样，才能适应用户的市场扩展得可能性。

软件架构的目标可定制化（CuSTomizable）。

同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。

可扩展性（Extensible）。

在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展。

可维护性（MAIntainable）。

软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。

一个易于维护的系统可以有效地降低技术支持的花费。

客户体验（CustomerExperience）。

软件系统必须易于使用。

市场时机（TimetoMarket）。

软件用户要面临同业竞争，软件提供商也要面临同业竞争。

以最快的速度争夺市场先机非常重要。

架构的种类逻辑架构软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等。

例子：

比如管控的逻辑层次，即表象层次，商业层次和数据持久层次。

每一个层次都含有多个逻辑元件。

比如WEB服务器层次中有HTML服务元件、Session服务元件、安全服务元件、系统管理元件等。

架构的种类物理架构软件元件是怎样放到硬件上的。

比如管控所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。

架构的种类系统架构系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。

系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。

架构设计的存在首先，一个软件系统中的元件首先是逻辑元件。

这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。

其次，进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。

这些决定中会有很多是一旦作出，就很难更改的。

根据作者的经验，一个基于数据库的系统架构，有多少个数据表，就会有多少页的架构设计文档。

比如一个中等的数据库应用系统通常含有一百个左右的数据表，这样的一个系统设计通常需要有一百页左右的架构设计文档。

视图视图视图编辑我们决定以多种构架视图来表示软件构架。

每种构架视图针对于开发流程中的涉众（例如最终用户、设计人员、管理人员、系统工程师、维护人员等）所关注的特定方面。

视图分类用例视图，这些用例和场景包括在构架方面具有重要意义的行为、类或技术风险。

它是用例模型的子集。

逻辑视图：

包括最重要的设计类、从这些设计类到包和子系统的组织形式，以及从这些包和子系统到层的组织形式。

它还包括一些用例实现。

它是设计模型的子集。

实施视图：

包括实施模型及其从模块到包和层的组织形式的概览。

同时还描述了将逻辑视图中的包和类向实施视图中的包和模块分配的情况。

它是实施模型的子集。

进程视图：

包括所涉及任务（进程和线程）的描述，它们的交互和配置，以及将设计对象和类向任务的分配情况。

只有在系统具有很高程度的并行时，才需要该视图。

在RationalUnifiedProcess中，它是设计模型的子集。

配置视图：

包括对最典型的平台配置的各种物理节点的描述以及将任务（来自进程视图）向物理节点分配的情况。

只有在分布式系统中才需要该视图。

它是部署模型的一个子集。

构架视图记录在软件构架文档中。

您可以构建其他视图来表达需要特别关注的不同方面：

用户界面视图、安全视图、数据视图等等。

形式形式构架模式构架模式是解决复杂构架问题的现成形式。

构架框架或构架基础设施（中间件）是可以在其上构建某种构架的构件集。

许多主要的构架困难应在框架或基础设施中进行解决，而且通常针对于特定的领域：

命令和控制、MES、控制系统等等。

形式形式1.通用层严格的分层构架规定设计元素（类、构件、包、子系统）只能使用下层提供的服务，服务可以包括事件处理、错误处理、数据库访问等等。

相对于记录在底层的原始操作系统级调用，它包括更明显的机制。

2.业务系统层上图显示了另一个分层示例，其中有垂直特定应用层、水平层和基础设施层。

注意：

此处的目标是采用非常短的业务“烟囱”并实现各种应用程序间的通用性。

否则，就可能有多个人解决同一问题，从而导致潜在的分歧。

3.数据持久层设计编辑描述语言为了讨论和分析软件构架，必须首先定义构架表示方式，即描述构架重要方面的方式。

在RationalUnifiedProcess中，软件构架文档记录有这种描述。

如ASS是化验、CDC是调度等设计编辑视图构架构架视图的图形描述称为构架设计图。

对于以上描述的各种视图，设计图由以下统一建模语言图组成UML99：

逻辑视图：

类图、状态机和对象图。

进程视图：

类图与对象图（包括任务-进程与线程）。

实施视图：

构件图。

部署视图：

配置图。

用例视图：

用例图描述用例、主角和普通设计类；顺序图描述设计对象及其协作关系。

流程流程在RationalUnifiedProcess中，构架主要是分析设计工作流程的结果。

当项目再次进行此工作流程时，构架将在一次又一次迭代中不断演化、改进、精炼。

由于每次迭代都包括集成和测试，所以在交付产品时，构架就相当强壮了。

构架是精化阶段各次迭代的重点，构架的基线通常会在此阶段结束时确定。

随机谈谈（为什么需要架构师）并发数大数据量业务变化无常，定制；接口速度构件化易用等