软件建模与设计(2)

不同的软件架构的定义




架构是对软件系统组织，结构部分和系统包含接口的选择，集合 部分的特定行为，较大子系统部分的构成和架构风格的重大决定 的设置。[Kruchten] 系统或计算系统的软件架构是包含软件部分，外部可见特性部分， 和他们之间的关系的系统的结构。[BASs et al.] [架构]是系统的组织结构和相关行为。架构可被重复分解为通过 接口，互联部分的关系和结合部相互作用的部分。通过接口相互 作用的部分包括类，组件和子系统。[UML 1.5] 软件架构或系统由组成系统的结构的相互作用和软件结构的重要 设计决定组成。设计决定应成功实现所期望支持的质量。设计决 定为系统开发，支持和维护提供概念上的基础。 [McGovern]
2015/8/28
2-
5
架构风格--背景


对软件体系架构风格的研究和实践促进了对设计 的复用，一些经过实践证实的解决方案也可以可 靠地用于解决新的问题。 架构风格的不变部分使不同的系统可以共享同一 个实现代码。只要系统是使用常用的、规范的方 法来组织，别的设计者就能很容易地理解系统的 体系架构。
2015/8/28
2-
21
软件架构视图
Logical View
Analysts/ Designers Structure
Implementatio n View
Programmers Software Management
End-user Functionality
Use-Case View
System Integrators Performance Scalability Throughput
2015/8/28
2-
16
软件架构设计的目标






可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为 重要，因此软件系统必须非常可靠。 安全行（Secure）。软件系统所承担的交易的商业价值极高，系统 的安全性非常重要。 可扩展性（SCAlable）。软件必须能够在用户的使用率、用户的数 目增加很快的情况下，保持合理的性能。只有这样，才能适应用户 的市场扩展得可能性。 可定制化（CuSTomizable）。同样的一套软件，可以根据客户群的 不同和市场需求的变化进行调整。 可扩展性（Extensible）。在新技术出现的时候，一个软件系统应当 允许导入新技术，从而对现有系统进行功能和性能的扩展。 可维护性（MAIntainable）。软件系统的维护包括两方面，一是排 除现有的错误，二是将新的软件需求反映到现有系统中去。一个易 于维护的系统可以有效地降低技术支持的花费。 客户体验（Customer Experience）。软件系统必须易于使用。 市场时机（Time to Market）。软件用户要面临同业竞争，软件提供 商也要面临同业竞争。以最快的速度争夺市场先机非常重要。
2015/8/28
2-
17
软件架构的种类

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

物理架构、软件元件是怎样放到硬件上的。
2015/8/28
2-
19
软件架构的种类


系统架构、系统的非功能性特征，如可扩展性、 可靠性、强壮性、灵活性、性能等。系统架构的 设计要求架构师具备软件和硬件的功能和性能的 过硬知识，这一工作无疑是架构设计工作中最为 困难的工作。 软件架构的两要素：元件划分和设计决定
27
2015/8/28
软件架构

“组件”贯穿于这些定义包括了对象，技术组件（例如 Enterprise JavaBean），服务，程序模块，遗留系统，应用程序 等。这些是 UML 2.0中对“组件”的定义：

[组件]是包括内容的系统模型部分，且它的显示是可替换的。组件 定义了所需接口的行为。例如，组件类似类型(type)，它与所需接 口行为一致。（包括静态和动态语义）
220
2015/8/28
软件架构视图

多种架构视图来表示软件架构 在 Rational Unified Process 中，一个典型的视图集开始， 该视图集称为“4+1 视图模型”




用例视图：包括用例和场景，这些用例和场景包括在架构方面具 有重要意义的行为、类或技术风险。它是用例模型的子集。 逻辑视图：包括最重要的设计类、从这些设计类到包和子系统的 组织形式，以及从这些包和子系统到层的组织形式。它还包括一 些用例实现。它是设计模型的子集。 实施视图：包括实施模型及其从模块到包和层的组织形式的概 览。 同时还描述了将逻辑视图中的包和类向实施视图中的包和 模块分配的情况。它是实施模型的子集。 进程视图：包括所涉及任务（进程和线程）的描述，它们的交互 和配置，以及将设计对象和类向任务的分配情况。只有在系统具 有很高程度的并行时，才需要该视图。 在 Rational Unified Process 中，它是设计模型的子集。 配置视图：包括对最典型的平台配置的各种物理节点的描述以及 将任务（来自进程视图）向物理节点分配的情况。只有在分布式 系统中才需要该视图。它是部署模型的一个子集。
2015/8/28
2-
12
软件架构

平衡涉众需求




架构是为了实现涉众的需要而创造的。但是，一般来说不可能满 足所有的需求。 不同的涉众之间可能有相互冲突的需求，所以应满足适当的平衡 性。 折衷是构建进程的主要方面，且妥协是架构的重要属性。 非功能需求经常是架构师所关注的最重要的需求。 例如：

例如，如果某人把系统描述为"客户／服务器"模式， 则不必给出设计细节，我们立刻就会明白系统是如何 组织和工作的
2015/8/28
2-
6
软件架构

软件架构是在组件，彼此之间以及与环境之间的 关系，引导设计发展原则中体现的系统的基本结 构。[IEEE 1471]

源自文库



系统是为实现某个（些）特殊作用的组件的集合。专 用系统包括个人应用，传统概念上的系统，子系统， 系统中的系统，产品线，产品系列，整个企业和其他 利益集团。一个系统是为了实现一个或多个任务而存 在。[IEEE 1471] 环境决定了开发，操作，策略和其他影响系统的设置 和条件。[IEEE 1471] 任务是指系统为了实现对对象设置的使用或操作。 [IEEE 1471] 涉众是对于系统有利益关系或关注的个人，团队或组 织。[IEEE 1471]
28
2015/8/28
软件架构

结构


结构是架构的基础属性。架构会以各种形式展示他们 自己，一个结构组件可能是一个子系统，进程，库， 数据库，计算结点，馈赠系统，按需产品等等。 许多架构的定义不但承认了他们自己的结构元素，而 且还有结构元素的组成，关系（任何连接部分都需支 持这样的关系），接口。这些部件都以不同方式被提 供。例如，连接段可以是套接字，同步的或异步的， 与某个协议相关等。




最终用户关心直觉，正确的行为，性能，可靠性，可用性，有效性 和安全性。 系统管理员关注直觉行为，管理和辅助监测。 业务人员关注有竞争力的特性，市场的时效性，对于其他产品的定 位和开销。 客户关注开销，稳定性和计划性。 开发者关注清晰的需求和简单而一致的设计方法。 项目经理关注追踪项目，计划，资源的生产使用和预算的可预见性。 维护人员关注易理解性，一致性，和文档化的设计方法，与易修改 性。


一个软件系统中的元件首先是逻辑元件。这些逻辑元 件如何放到硬件上，以及这些元件如何为整个系统的 可扩展性、可靠性、强壮性、灵活性、性能等做出贡 献，是非常重要的信息。 进行软件设计需要做出的决定中，必然会包括逻辑结 构、物理结构，以及它们如何影响到系统的所有非功 能性特征。这些决定中会有很多一旦作出，就很难更 改的。
2015/8/28
2-
9
软件架构

结构元素的例子 ：显示了包含展示顺序进程系统的结 构部分的UML类图
2015/8/28
2-
10
软件架构

行为：与定义结构元素一样，架构定义了这些结 构元素的相互作用。这些作用可以实现所期望的 系统行为。
2015/8/28
2-
11
软件架构

重要元素：



当一个架构定义了结构和行为，它不会在意所有的结 构和行为的定义。它只在意那些被认为是重要的元素。 重要的元素是那些有持久影响的，例如结构部分的主 要部分，与核心行为相关的元素，和对诸如可靠性和 可测量性等重要品质相关的元素。 总的来说，架构不关心这些元素的细节。架构的重要 性还可以以经济的重要性来表达，因为某些元素的主 要驱动者是创建的成本和变更的成本。 重要元素的设置可能会改变。但是，面对改变的架构 的稳定性是好的架构，好的可执行架构进程，是好的 架构师的标志。
Process View
Deployment System Engineering View
System Topology Delivery, installation communication

层的弱点


2015/8/28
2-
14
软件架构的层次模型

软件架构的三层结构




三层结构：表示（presentation）层, 领域（domain） 层, 以及基础架构（infrastructure）层。 表示层逻辑，主要处理用户和软件的交互。现在最流 行的莫过于视窗图形界面（wimp）和基于html的界面 了。表示层的主要职责就是为用户提供信息，以及把 用户的指令翻译。传送给业务层和基础架构层。 领域层逻辑，有时也被叫做业务逻辑。它包括输入和 存储数据的计算。验证表示层来的数据，根据表示层 的指令指派一个基础架构层逻辑。 基础架构层逻辑，包括处理和其他系统的通信，代表 系统执行任务。例如数据库系统交互，和其他应用系 统的交互等。大多数的信息系统，这个层的最大的逻 辑就是存储持久数据。
软件建模与设计(2)
建筑风格——古希腊、古罗马建筑
2015/8/28
2-
2
建筑风格——哥特建筑
2015/8/28
2-
3
中国建筑
2015/8/28
2-
4
架构风格-- 背景


软件体系架构设计的一个 核心问题 是 能否重复 使用 体系架构模式，即能否达到体系架构级的 软件重用。也就是说，能否在不同的软件系统中， 使用同一体系架构。基于这个目的，研究人员开 始研究和实践 软件体系架构的风格和模式问题 软件体系架构模式 是描述某一特定应用领域中 系统组织的惯用方式。它反映了领域中众多系统 所共有的架构和语义特性，并指导如何将各个模 块和子系统有效地组织成一个完整的系统。
215
2015/8/28
软件架构的层次模型

其它的层模型



Brown model:有五个层：表示层（Presentation），控制/中介层 （Controller/Mediator），领域层（Domain）, 数据映射层 （Data Mapping）, 和数据源层（Data Source）。它其实就是在 三层架构种增加了两个中间层。控制/中介层位于表示层和领域 层之间，数据映射层位于领域层和基础架构层之间。 J2EE的分层架构：客户层（Client），表示层（Presentation）， 业务层（Business ），整合层（Integration），资源层 （Resource）。 客户层是运行在客户机上的表示层；表示层是 运行在服务器上的表示层； 业务层是领域层；整合层是基础架 构层；资源层是基础架构层通信的外部数据。 微软的DNA架构定义了三个层：表示层（presentation），业务 层（business），和数据存储层（data access），这和前面的三 层架构相似，但是在数据的传递方式上还有很大的不同。在微软 的DNA中，各层的操作都基于数据存储层传出的SQL查询结果集。 这样的话，实际上是增加了表示层和业务层同数据存储层之间的 耦合度。
2015/8/28
2-
13
软件架构的层次模型

层（layer）这个概念在计算机领域是非常了不 得的一个概念。

层的好处：


你使用层，但是不需要去了解层的实现细节。 可以使用另一种技术来改变基础的层，而不会影响上面的层 的应用。 可以减少不同层之间的依赖。 容易制定出层标准。 底下的层可以用来建立顶上的层的多项服务。 层不可能封装所有的功能，一旦有功能变动，势必要波及所 有的层。 效率降低。