架构建模总结

1、什么是软件架构？



2、课程安排



3、技术的深度和广度怎么选择去平衡？

一定要先足够深入，没有深度的广度都是表面的，很难做到举一反三，所以要优先深度。

4、使用UML（统一建模语言）建模

静态关系

• 用例图

• 对象图

• 类图

• 组件图

• 包图

• 部署图

动态关系

• 序列图

• 活动图

• 状态图

• 协作图

统一建模语言提供了6中静态图描述静态关系，4中动态图描述交互关系，再结合各类关联表述和消息表述，能使用比较少的元素表达更多的信息量，在4 + 1视图中可以灵活选取合适的UML建模方式（形式不重要，可以不严谨）再配以文字描述，目的只有一个，把问题和方案描述清楚。



5、4 + 1 视图模型：软件开发的本质是什么？ 如何进行软件架构设计？



以上是智慧老师的解答，另外附上博客园帖子：

基于UML 4+1视图和概念模型的建模方法（贴）

RUP的4+1视图包括： 逻辑视图：关注功能性的、整个系统的抽象结构，不涉及具体的编译即输出和部署。 开发视图：是逻辑视图的实现，描述程序生成多少个exe、dll、jar、配置文件等。又叫实现视图。 运行视图：关注程序运行时各个子系统、组件之间的交互策略。如多进程、多线程，生产者-消费者模式。运行视图又称过程视图。 部署视图：关注软件交付以后在机器上的部署形态，以及和上下文的关系。又称物理视图。 用例视图：关注需求，又叫场景视图。

RUP 4+1视图相对完整的描述了从需求分析到系统设计的过程，但没有专门针对数据持久层的描述。温li在软件架构设计中用数据视图替换了用例视图，应该说他相对重视架构设计，对需求关注的少一些。

关于需求的描述方法，应当清醒的看到，仅仅通过用例视图是不够的，用例技术涉及、但无法全面涵盖非功能需求。需求 = 功能 + 质量 + 约束。大量的信息还是要通过详细的文字描述才能够讲清楚。用例视图只不过提供了描述了一个软件的需求概貌。除了用例视图以外，还应该关注软件的概念模型（又称领域模型、信息模型）。如果说用例着重于描述一个个具体的需求，概念模型则从业务的角度描述了整个软件系统所要完成的功能中涉及的所有概念以及彼此之间的关系。例如对于一个网管系统，核心的两个概念是设备和端口，端口从属于设备，他们之间是多对一的关系。

分别详述4+1视图：

逻辑视图关注的静态元素是：层、子系统、类、接口，用类图来描述。关注的动态因素是协作关系，用时序图、协作图、状态图等来描述。是否需要在架构设计中体现类和类之间的关系？这取决于设计的层级。

开发视图关注的元素是程序包（SDK、解析器、中间件）、文件组织结构、编译依赖关系、目标单元（jar、exe、dll等）。它和逻辑视图的静态元素通常有映射关系。

运行视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。运行架构和开发架构的关系：开发架构一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，运行架构比较关注的是这些运行时单元的交互问题。

部署视图关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。部署视图和运行视图的关系：运行视图特别关注目标程序的动态执行情况，而部署视图重视目标程序的静态位置问题；部署视图还要考虑软件系统和包括硬件在内的整个IT系统之间是如何相互影响的。

文中提到一个观点非常的赞同：需求 = 功能 + 质量 + 约束，所以仅通过用例视图描述需求是不够的，这也正呼应了智慧老师提到的设计文档需要对非功能性需求进行描述。

6、4 + 1 视图模型补充资料

“4+1”视图模型

“4+1”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。

每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件体系结构的全部内容。





逻辑视图（对象视图）

标记符号：





逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。（感觉就是类和类服务）

在面向对象技术中，通过抽象，封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。

逻辑视图中使用的风格为面向对象的风格，逻辑视图设计中要注意的主要问题是要保持一个单一的、内聚的对象模型贯穿整个系统。

笔者观点：逻辑视图就是把功能模块分出来，功能模块封装成类，然后对象类与功能类之间所有的关系表示出来就可以了。

下面是一个通信系统体系结构（ASC，communication system Architecture）的逻辑视图：





开发视图（模块视图）

标记符号：





开发视图也称模块视图，主要侧重于软件模块的组织和管理。

开发视图要考虑软件内部的需求，如软件开发的容易性、软件的重用和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。

开发视图通过系统输入输出关系的模型图和子系统图来描述。

在开发视图中，最好采用4-6层子系统，而且每个子系统仅仅能与同层或更低层的子系统通讯，这样可以使每个层次的接口既完备又精练，避免了各个模块之间很复杂的依赖关系。

设计时要充分考虑，对于各个层次，层次越低，通用性越强，这样，可以保证应用程序的需求发生改变时，所做的改动最小。开发视图所用的风格通常是层次结构风格。

笔者观点：开发视图就是将系统分成4-6层，越底层的就越通用也越小，底层的可以组成上一层的，相邻两层的联系比较大，感觉这里面的界限比较难确定。

一个例子：





进程视图（过程视图）

标识符号：





进程视图侧重于系统的运行特性，主要关注一些非功能性的需求。

进程视图强调并发性、分布性、系统集成性和容错能力，以及从逻辑视图中的主要抽象如何适合进程结构。它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。

进程视图可以描述成多层抽象，每个级别分别关注不同的方面。在最高层抽象中，进程结构可以看作是构成一个执行单元的一组任务。它可看成一系列独立的，通过逻辑网络相互通信的程序。它们是分布的，通过总线或局域网、广域网等硬件资源连接起来。

笔者观点：进程视图就是逻辑视图中一个具体功能是怎样在线程中执行的。描述的是逻辑视图中的工作细节。

一个例子：





物理视图（部署视图）

标识符号：





物理视图主要考虑如何把软件映射到硬件上，它通常要考虑到系统性能、规模、可靠性等。解决系统拓扑结构、系统安装、通讯等问题。

当软件运行于不同的节点上时，各视图中的构件都直接或间接地对应于系统的不同节点上。因此，从软件到节点的映射要有较高的灵活性，当环境改变时，对系统其他视图的影响最小。

笔者观点：物理视图就是分配构件的物理资源，将构件或进程的物理资源分配情况展示出来。

一个例子：





大型系统的物理视图可能会变得十分混乱，因此可以与进程视图的映射一道，以多种形式出现，也可单独出现。

例子（具有进程分配的大型ACS系统的物理视图）：





场景视图（用例视图）

场景可以看作是那些重要系统活动的抽象，它使四个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。在开发体系结构时，它可以帮助设计者找到体系结构的构件和它们之间的作用关系。同时，也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何相互作用的。

笔者观点：场景视图就是描述现实中的一个系统运用场景的过程，把其中牵涉到的对象，服务和操作都展示出来。

例子：





逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。

对于不同的软件系统来说，侧重的角度也有所不同。例如，对于管理信息系统来说，比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统来说，则比较注重于从进程视图和物理视图来描述系统。

建模工具和符号的选择：没有统一规定。



7、架构设计的阶段，暨设计文档结构



阶段划分



需求分析阶段（关注问题域）

• 需求建模：建立场景视图模型、提出非功能性约束

• 分析建模：建立逻辑视图模型

• 完成架构设计文档的功能概述部分

方案设计阶段（关注解域）

• 设计建模：建立开发视图模型、物理视图模型、进程视图模型

• 该阶段产出设计文档的具体设计，按照抽象层级自顶向下，先整体后局部的逐层展开过程描述整个设计方案

• 概要设计：描述系统部署与整体设计（抽象层级是系统和子系统）

• 详细设计：描述子系统和子系统的内部组件设计（抽象层级是组件和组件内部结构）