1、软件体系结构及应用2 SA核心概念及其建模,1,主要内容,2.1 SA的核心概念 构件与连接件2.2 SA建模需求 为什么要建立SA模型？2.3 SA多视图模型 一千个人眼里有一千个哈姆莱特 2.4* SA的生命周期 不同的阶段有不同的设计任务,2,2.1 SA的核心概念,3,回忆：SA的定义,软件体系结构(SA)： 提供了一个结构、行为和属性的高级抽象 从一个较高的层次来考虑组成系统的构件、构件之间的连接，以及由构件与构件交互形成的拓扑结构 这些要素应该满足一定的限制，遵循一定的设计规则，能够在一定的环境下进行演化。 反映系统开发中具有重要影响的设计决策，便于各种人员的交流，反映多种关注，据
2、此开发的系统能完成系统既定的功能和性能需求。体系结构= 构件+ 连接件+ 拓扑结构+ 约束+ 质量 Architecture = Components + Connectors + Topology + Constraints + Performance,4,SA中的核心概念,5,2.1.1 构件(Component),6,构件(Component),构件是具有某种功能的可复用的软件结构单元，表示了系统中主要的计算元素和数据存储。 任何在系统运行中承担一定功能、发挥一定作用的软件体都可看作是构件。 程序函数、模块 对象、类 数据库 文件 .,7,接口(Interface)与服务(Service
3、),构件作为一个封装的实体，只能通过其接口(Interface)与外部环境交互，表示了构件和外部环境的交互点； 内部结构则被隐藏起来(Black-box)； 一个构件至少有一个接口； 一个构件可以提供多重接口；WHY?构件内部所实现的功能以服务(Service)的形式体现出来，并通过接口向外发布，进而产生与其它构件之间的关联。The interface of a component is deliberately kept separate from the implementation of that module (构件接口与其内部实现应尽可能严格分开). WHY？,8,构件的粒度(Gra
4、nularity),9,粒度的定义(Granularity),Granularity: the relative size, scale, level of detail, or depth of penetration that characterizes a component. (构件的相对大小、规模、细节程度或关注程度的一个属性)。 国家-省份-地区-城市-街道 原子构件(Atomic component)：不可再分解。 砖、瓦 集成电路、芯片 数据结构、函数 复合构件(composite component)：由其他原子构件与复合构件通过连接而成。 预制板、房屋框架 存储器、运算器、
5、控制器 对象、模块、子系统,10,粒度对构件的影响,When a system is split into components, its important to get the right degree of componentization. (恰当的粒度是很重要的)Small, fine-grained components give much greater flexibility in assembling precisely the right combination of functionality, but they are more difficult to co-ordi
6、nate. (小粒度构件：灵活性高，复用度高，但交互复杂，使用效率低下)Much larger, coarse-grained components are easier to manage but may become too unwieldy. (大粒度构件正好相反)WHY?,11,体系结构中构件粒度的演变,系统(程序) = 算法+ 数据结构(1960s ) 系统= 子程序+ 子程序(1970s ) 系统= 对象+ 对象关联机制(1980s ) 系统= 软构件+ 连接件(1990s ) 系统= 服务+ 服务连接件(2000s),12,2.1.2 连接与连接件 (Connection and
7、 Connector),13,连接(Connection),连接(Connection)：构件间建立和维护行为关联与信息传递的途径； 连接需要两方面的支持： 连接发生和维持的机制实现连接的物质基础(连接的机制)； 连接能够正确、无二义、无冲突进行的保证连接正确有效的进行信息交换的规则(连接的协议)。简称“机制”(mechanism)和“协议”(protocol)。,14,连接的机制(Mechanism),计算机硬件提供了一切连接的物理基础： 过程调用、中断、存储、堆栈、串行I/O、并行I/O等； 基础控制描述层： 过程调用、动态约束、中断/事件、流、文件、网络等； 资源及管理调度层： 进程、线
8、程、共享、同步、并行、分时并发、事件、消息、异常、远程调用、注册表、剪贴板、动态连接、API等； 系统结构模式层： 管道、解释器、编译器、转换器、浏览器、中间件、ODBC等。,15,连接的协议(Protocol),协议(Protocol)是连接的规约(Specification)； 连接的规约是建立在物理层之上的有意义信息形式的表达规定 对过程调用来说：参数的个数和类型、参数排列次序； 对消息传送来说：消息的格式； 对ODBC数据库连接来说：SQL语言； 对Web Service连接而言：SOAP或REST协议； 目的：使双方能够互相理解对方所发来的信息的语义。,16,现实中的“连接”,17,
9、连接的种类,从连接目的看： 操作/过程调用； 控制/事件/消息发送； 数据传输； 其他目的？ 除了连接机制/协议的实现难易之外，影响连接实现复杂性的因素之一是“有无连接的返回信息和返回的时间”，分为： 同步(Synchronous) 异步(Asynchronous),18,连接的特性(1),方向性 主控方和被控方：谁控制连接？谁只是参与连接？ 信息的发送方与接收方：谁发送信息？谁接收信息？ 在一般的连接中，通常伴有双向的信息交换。角色：连接的双方所处的不同地位的表达 过程调用：调用方(Caller)和被调用方(Callee) 管道：读取方(Reader)和写入方(Writer) 消息传递：发送
10、者(Sender)和接收者(Receiver) (不同的体系结构风格中拥有不同的角色),19,连接的特性(2),激发性：定义为“引起连接行为的方式”，分为主动方和被动方的激发性： 主动方：操作调用、事件触发 被动方：状态查询、事件触发 连接的发出方式有1:1(点对点)和1:n 响应特性：包括连接的被动方对连接请求的处理实时性、时间、方式、并发处理能力等 同步/异步(Synchronous/Asynchronous) 并发/互斥(Concurrency/Mutually exclusive),20,连接件(Connector),连接件(Connector)：表示构件之间的交互并实现构件之间的连接
11、，如： 管道(pipe) 过程调用(procedure call) 事件广播(event broadcast) 客户机-服务器(client-server) 数据库连接(SQL)连接件也可看作一类特殊的构件，区别在于： 一般构件是软件功能设计和实现的承载体； 连接件是负责完成构件之间信息交换和行为联系的专用构件。,21,2.2 软件体系结构建模需求,22,问题：什么是模型？,E-R模型/ IDEF1x模型 UML模型功能分解模型 业务过程模型 信息模型 组织模型 ,23,建立模型的目的,“模型”的定义： 系统、理论或现象的图解性的描述，用来描绘其已知的或推测性质的特性，也用于深入研究它们的特点
12、； 表示物理/生物/社会过程的模型，具有一组变量以及作用在这组变量之上的逻辑或数量关系； 建立模型的目的： 提供一个理想的论证框架，应用逻辑和数学工具，评估性能，并在多个类似的场景下进行推理。 Idealized means that model may make explicit assumptions that are known to be false in some detail (理想化：做出一些假设，忽略细节). Models are an important component of scientific theories (以建立科学理论).,24,为什么要建立SA模型,针对某
13、一具体的软件系统研发项目，需要以某种可视化/形式化的形式将SA的设计结果加以显式的表达出来，进而支持： 用户、软件架构师、开发者等各方人员之间的交流； 分析、验证SA设计的优劣； 指导软件开发组进行系统研发； 为日后的软件维护提供基本文档。,25,SA建模的三个层次,图形化模型：SA模型的多视图表示(Multi-view graphical model) 从不同的视角描述特定系统的体系结构，从而得到多个视图，并将这些视图组织起来以描述整体的SA模型； 形式化模型：SA描述语言(Formal architecture description language, ADL) 在SA基本概念的基础上，
14、选取适当的形式化或半形式化的方法来描述一个特定的体系结构； 文档化模型：SA文档化(Documentation) 记录和整理软件体系结构设计方案的各类细节。,26,2.3 软件体系结构的多视图模型,27,使用“多视图模型”进行SA建模的原因,考虑建筑体系结构的描述： 房间布局图、电路图、管道图、等等；A software architecture is a complex entity that cannot be described in a simple one-dimensional fashion (软件体系结构非常复杂，无法用简单的一维模型加以描述).多视图SA模型：从多个不同角度建
15、立SA的模型，分别刻画SA某一方面的性质。 系统的每一个不同的视图反映了一组系统相关人员所关注的系统的特定方面； 多视图体现了“关注点分离”(separation of concerns)的思想，使系统更易于理解，方便系统相关人员之间进行交流，并且有利于系统的一致性检测以及系统质量属性的评估。,28,关于SA的IEEE标准1471-2000,29,IEEE1471: Stakeholders & their concerns,30,SA的“视图观”,(Kruchten) 4+1模型 统一建模语言UML(Hofmesiter) 4视图模型(CMU-SEI) Views and Beyond模型
16、(ZIFA)Zachman框架 开放分布式处理参考模型(RM-ODP),31,RM-ODP的视图观,32,Zachman Framework的视图观,33,(Kruchten)4+1视图模型,Kruchten在1995年提出了“4+1”的视图模型。“4+1”视图模型从5个不同的视角(逻辑视图、进程视图、物理视图、开发视图和用例视图)来描述软件体系结构。每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件体系结构的全部内容。该模型已被广泛应用于UML和RUP中。,34,(Kruchten) 4+1视图模型结构,35,逻辑视图(Logical View),逻辑视图主要支持系统的功能
17、性需求，即系统提供给最终用户的服务。 在逻辑视图中，系统分解成一系列的功能抽象(classes, interfaces, and patterns)，这些抽象主要来自用户需求所在的问题领域，同时也表达了软件领域的相应概念。 这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。 The logical view typically doesnt address how the system will be implemented or executed. (逻辑视图通常并不描述软件系统是如何被实现或执行),36,逻辑视图的UML表示,在UML中，逻辑视图
18、通常使用以下的图形表达形式 Class diagrams (类图) Activity diagrams (活动图) Sequence diagrams (次序图) Composite structure diagrams (组合结构图),37,逻辑视图的UML表示,38,逻辑视图的UML表示,39,开发视图(Implementation View),开发视图也称模块视图(Module View)，主要侧重于软件模块的组织和管理。 系统-子系统-模块(构件、文件、资源等)，并组织成层次结构 开发视图的另一个焦点在于：描述各模块之间的依存关系。 What components depend on
19、what, what source files implement what classes, etc. (例如：一个构件的实现依赖于哪些其他构件、哪些源文件实现了哪些类，等等。) 开发视图要考虑软件内部的实现需求，如软件开发的容易性、软件的复用和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。,40,开发视图的UML表示,在UML中，开发视图通常使用以下的图形表达形式 Component diagrams (构件图),41,42,进程视图(Process View),进程视图侧重于系统的运行特性，主要关注一些非功能性的需求。 并发性、分布性、系统集成性和容错能力； 逻辑视图中的
20、各个抽象概念如何在进程中被执行； 逻辑视图中的各个类的操作具体是在进程中的哪一个线程中被执行的。,43,进程视图的UML表示,Process views often use some form of the following diagrams to show how a system actually behaves at runtime: (在UML中，进程视图通常使用以下UML图来描述一个系统的运行时行为) Activity diagrams (活动图) Interaction diagrams (交互图) Sequence diagrams (次序图) Communication di
21、agrams (通讯图) Interaction overview diagrams (交互预览图) Timing diagrams (时间图),44,进程视图的UML表示,UML Activity Diagram,45,物理视图(Physical View),物理视图主要考虑如何把软件映射到硬件上； 它通常要考虑系统性能、规模、可靠性等；解决软件系统配置、安装、系统部署后的物理拓扑结构、系统执行过程中的通讯问题等。,46,物理视图的UML表示,The physical view often consists of (在UML中，物理视图通常包括) Deployment diagrams (配
22、置图) Package diagrams (包图) Interaction diagrams (交互图),47,物理视图的UML表示,48,用例视图(Use Case View),用例视图用来捕获最终用户所需求的功能性，即“系统应该做什么”； 用例视图使其他四个视图有机的联系起来。用例视图也称为场景(Scenario)。The use case view includes use case diagrams and typically uses several interaction diagrams to show use case details. (在UML中，用例视图主要包括用例图，然
23、后使用若干个交互图来展示每个用例内部的细节),49,用例视图的UML表示,50,51,总结：(Kruchten)4+1视图模型,逻辑视图：描述系统的抽象概念与功能(类、对象、接口、模式等)，主要图形包括class diagrams, sequence diagrams, and collaboration diagrams等； 开发视图：描述系统中的子系统、模块、文件、资源及其之间的关系，主要图形包括component diagrams等； 进程视图：描述系统的进程及其之间的通信协作关系，主要图形包括activity diagram, interaction diagram等； 物理视图：描述
24、系统如何被安装、部署与配置在分布式的物理环境下，主要图形包括deployment diagram等。用例视图：描述系统的典型场景与功能，主要图形包括use case diagram等。,52,总结：(Kruchten)4+1视图模型,4+1视图模型是一种已经被标准化(UML, RUP)的方法，用来描述和文档化软件系统的体系结构。每个视图从不同的角度刻画了系统的结构属性，将它们综合在一起就形成了系统的整体架构。 逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。 对于不同类型的软件系统来说，侧重的角度也有所不同。,53,2.4* 软件体系结构生命周期模型,54,SA在
25、软件生命周期中的位置,55,SA的生命周期模型,56,SA的生命周期模型,Phase 1: informal description (SA的非形式化描述) Phase 2: specification and analysis (SA的规范描述与分析)Phase 3: refinement and verification (SA的求精及其验证) Phase 4: enactment (SA的实施) Phase 5: evolution and extension (SA的演化和扩展) Phase 6: provision, evaluation and metrics (SA的评价与度量) Phase 7: termination (SA的终结),57,结 束,58,
