软件体系结构笔记Software Architecture

如将本文作为包老师课的知识框架作业的参考，请加以改动再进行提交，谢谢配合～

本文将软件体系结构的主要笔记整理出来，主要用于自己的复习和回顾。部分内容参考自：包尔老师的软件课程吧

Chapter1. 软件体系结构介绍 Introduction

软件体系结构 ≈ 软件设计

详细阐述软件工程的设计阶段

1.1 软件发展的历史

汇编语言assemble language - 因为非常复杂，只能写一些非常小的程序，比如汉诺塔

1970 - 汇编->C，即高级程序语言，从C语言开始能写比较大的程序，但没有库函数，很多时候需要从头写。从C语言开始，就有了程序设计的问题，出现了面向结构的设计理念。

1980 - C++，java开始发展。（有很多库函数，出现了面向对象的设计理念）

面向对象和结构化的区别：

结构化程序分析设计时，每个模块按照顺序实现功能。面向对象的特征则是封装，可以进行信息的隐藏，也提高了复用性和可维护性。

面向对象的设计思想，从80年代开始，一直沿用到现在。目前多数软件都是面向对象的。

1995 ->框架：已经设计好的工具，便于我们实现一般性的软件。

开发时，每个模块把需要补充的东西填进去，就可以运行。

组件与库函数的区别：库需要与程序绑定在一起，引入到程序里面，一起编译，才算是真正用起来；组件则是独立于程序，多数是网上的服务，编译自己的程序后，在运行时直接调用组件就可以了。程序对组件的依赖程度更低。

技术是便于我们开发程序，但没有便于我们设计程序。当新技术出现后，程序设计变得越来越重要了。

未来->Model-Driven Development: MDA

程序：比较小的软件；软件/系统：比较大的软件。

软件抽象程度越来越高，不需要考虑细节，软件的实现变得越来越简单，软件的设计就越来越复杂和重要。

机器语言->汇编语言->高级语言advanced language->应用程序框架

结构化设计->面向对象的程序设计->面向方面的编程aspect-oriented programming

考试可能出的简答题：为什么软件设计越来越重要？

1.2 体系结构的定义

程序或计算系统的软件体系结构是系统的一个或多个结构，它包括软件元素、这些元素的外部可见属性以及它们之间的关系。

体系结构是系统的组织结构。一个体系结构可以被递归地分解为通过接口、连接部件的关系和组装部件的约束进行交互的部件。通过接口交互的部件包括类、组件和子系统。

软件体系结构是系统的基本组织，体现在其组件、组件之间的相互关系和环境，以及控制其设计和发展的原则中。

软件体系结构的组成：

• 元素elements：函数、接口、程序、类模块、层、子系统、客户端/服务端

• 属性properties：提供服务、性能特征、纠错处理、共享资源的使用

• 关系relationship：元素的组合机制和风格样式

软件体系结构的定义：组件以及组件之间的关系。Compoents comprised in the system, and the relationships or interaction mechanisms of those components.（注意：定义中还应该加上属性）

1.3 体系结构的相关概念related concepts

组件：

• 负责某些职责的系统的逻辑和功能单元

• 在不同的场景中可能是不同的特定对象：模块，子系统，层，包，类

• 可以分成更小的组件单位

组件之间的连接是多种多样的：顺序/三角/层次等

属性：分为功能性属性和非功能性属性

框架：针对特定问题的可重用应用程序基础结构。有必要的基本组件和连接器的指定问题基于它开发的应用程序的上下文或环境。J2EE框架、net框架等。

1.4 体系结构的影响因子influential factors

1. 利益相关者stakeholders：用户、服务提供商、设计/开发人员、公司管理层（开发组织）
2. 组织结构
3. 背景和架构师经验
4. 技术环境

更多利益相关者：最终用户、购买者、项目经理、系统工程师、软件开发者、软件架构师architect（注意：架构才是architectur）、运维工程师、其他开发人员

每个利益相关者对于软件的要求不同，关注的角度不同。如用户关注好用；购买者关注价格；项目经理关注任务分配；系统工程师（把软件系统安装在硬件上，架设服务器等）关注布设的简单程度、开发人员希望功能简单、架构师需要综合考虑、维护人员希望容易维护等等。

反馈循环：之前的系统开发成什么样，也会影响现在的系统开发成什么样。系统开发出来后，反而会对体系结构的影响因素有影响。

1.5 软件体系结构的好处benefits

从技术上来说，是承上启下的作用，将需求转化成设计，又能指导实现

从组织上来说，为stakeholders提供了一个交流的平台，满足所有stakeholder的需求。

1.6 当前的研究和应用current researches & practice

研究一些比UML更好的软件设计的描述语言

验证和评估的研究

ICSE：软件工程会议

Chapter2. 软件体系结构建模 Modeling

2.1 软件体系结构视图模型

模型是什么？

对现实世界的一个简化，一个缩小版；

模型提供了系统的一个蓝图；

模型可以是结构化的，也可以是动态的。

模型的作用：

模型帮助我们将系统形象化，或者将系统形象化；

模型为我们提供了一个模板，指导我们构建一个系统；

模型允许我们指定系统的结构或行为；

模型可以把我们的决定记录下来。

体系结构视图模型：软件设计的模型，使用工程制图的形式，因此称作软件体系结构视图模型。

2.2 4+1 视图模型

Philippe Kruchten

问题：不同的stakeholder有不同的软件设计理念和需求。

解决方法：看人下菜碟，根据不同的人，给出多个不同的模型。不需要给出太多模型，只需要给出4+1模型。

脚本模型：直接描述软件的功能性需求，属于需求分析的模型，而不是软件设计的模型。因此不和设计的模型放在一起。但是设计是从需求来的，因此它属于“4+1”中的“1”。

逻辑模型：描述系统有哪些组件，组件如何连接。从脚本模型，功能性需求，设计出来的。是设计模型中最主要的，剩下三个都是从逻辑模型里来的，描述的是非功能需求。逻辑模型主要是给最终用户看的，最终用户关心系统的功能。

开发模型：便于开发时分配任务。是给项目经理和软件开发人员看的。

过程模型：描述系统性能，影响软件速度的因素，如创建进程、多数描述的是组件之间发送消息。给系统集成的人看的。

物理模型：描述系统如何布设在硬件上，系统如何与硬件进行交互的。给系统工程师看的，软件如何放在硬件之上。

example：

脚本模型：时序图scenarios view。使用用例图描述脚本模型比用时序图更加合适。

逻辑模型：将组件和组件之间的连接画出来。应该画的是类图，而这里画出的是包图，非常简略。

开发模型：将上述的四个子系统分成了两组，用户交互/数据发送和网络交互的两组。

过程模型：描述系统有多少个线程。

物理模型：描述了与硬件的交互。

非常不符合规范、简单的例子，细节的设计都不涉及到，但它确实是按照“4+1”模型的思路画出来的。这是为什么呢？

因为这只是告诉我们这些模型大概应该什么样，却没有告诉我们具体的规范。没有一个标准、协议，作一个行业的规范。而规范就是下面要说的UML。

2.3 统一建模语言 UML(Unified Modeling Language)

UML出现的时间：1975-80年，80年后就成为了统一的一个标准

语言：用于交流。编程语言是人和计算机交流，统一建模语言是stakeholder之间交流。定义了基础元素和语法，把基础元素和语法结合起来，形成段落/