08 SA重点

更新时间:2024-01-05 13:11:01 阅读量: 教育文库 文档下载

说明:文章内容仅供预览,部分内容可能不全。下载后的文档,内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的,是否完整无缺。

SA重点整理

1. What is Architect and why architecture?

Good software is designed by a software architecture Booch, Rumbaugh, Jacobson, 1999:

An architecture is the set of significant(重要的) decisions about the organization of software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations(协作) among those elements, the composition of these structural and behavioral(动作的) elements into progressively(日益地) larger subsystems, and the architectural style that guides this organization – these elements and their interfaces, their collaborations, and their composition. 体系结构 = 组件 + 连接件 + 约束

Software Architecture = Components + Connectors + Constrains

2. 软件体系结构的风格(Architectural Styles)

1) 2) 3) 4)

定义

拓扑结构 优缺点

拓扑结构中每块的作用

A. Main Program and Subroutine

a) 特点: 典型的依据功能分解的编程模型 b) 拓扑结构:

c) 缺点: this pattern is suitable for applications in which the computation

can appropriately(适当地) be defined via a hierarchy of procedure definitions. 解决:

系统模块:层次化地调用和定义,子系统常常通过模块定义; 组件:过程和显式可见的数据 连接器:过程调用和显示数据共享 控制结构:单线程

B. Object Oriented

a) 定义: b) 拓扑结构:

c) 优缺点:this pattern is suitable for applications in which a central issue is identifying and protecting related bodies of information, especially representation information. 解决:

系统模块:局部状态维护

组件:管理(例如服务器,对象,抽象数据类型) 连接器:过程调用

控制结构:分散的(decentralized),通常多线程

d) 拓扑结构中每块的作用

C. Layered System

a) 定义: b) 拓扑结构:

c) 优缺点:this pattern is suitable for applications that involve(包含) distinct classes of services that can be arranged(安排) hierarchically. Often there are layers for basic system-level services, for utilities appropriate to many applications, and for specific tasks of the application. 解决:

系统模块:不透明(opaque)的层结构 组件:通常是组合的

连接器:依赖于组件的结构,通常过程调用限制为可见的,可能是client/server

控制结构:单线程

? 每层为上一层提供服务,使用下一层的服务,只能见到与自己邻接的层

– 适当时候(必不得已的时候),可以允许一定的越层操作

? 大的问题分解为若干个渐进的小问题,逐步解决,隐藏了很多复杂度

? 修改一层,最多影响两层,而通常只能影响上层。接口稳固,则谁都不影响

? 上层必须知道下层的身份,不能调整层次之间的顺序 ? 层层相调,影响性能

d) 拓扑结构中每块的作用:

D. Data Centered/Shared Data 拓扑结构:

优点:很容易增加数据的生产者和消费者

问题:synchronization(同步),configuration and schema management(配置和管理),atomicity(原子性),consistency(一致性),persistemce(持久性),performance(性能)

E. Repository Architecture

a) 定义: b) 拓扑结构:

c) 优缺点:适合这样的问题:建立(establishing),扩张(augmenting)和维护(maintaining)一个复杂信息的数据体。典型地,信息能以多种方式操作。通常长期的持久化也是必须的。 解决方案:

系统模块:以数据为中心

组件:一个存储器,多个纯计算处理器

连接器:计算单元通过在存储器中直接访问数据或者过程调用互相作用。

F. Blackboard

a) 定义:

知识源:把问题分成几个部分,每个部分独立计算;在黑板中响应变化;

黑板数据结构:全局数据库包含域的全部状态;知识源项目作用的唯

一媒介; 控制:完全由黑板的状态驱动,黑板的状态改变决定使用的特定知识;让知识源响应偶然事件

举例:信号处理,专家系统,模式识别等领域经常采用。 b) 拓扑结构

c) 优缺点:

没有直接的算法可解(多种方法都能解决问题,需要多个领域的专门知识协作解决);不确定性(数据和解决方法可能错误或者变化,数据中的信噪比会变化,算法借口会变化);没有唯一的答案,正确答案会变化

d) 拓扑结构中每块的作用

3. ADD属性驱动设计(Chapter 2)

ABD: Architecture-based Development, 使用架构作为其实现业务的基础部分,的开发。

ADD方法是一个一步一步的方法,用来系统化地构建系统的顶级架构设计。它需要以下输入:质量属性需求、功能需求、约束。

ATAM: Architecture Tradeoff Analysis Method,用来评估一个架构是否达到了我们希望达到的目的。

4. 4+1模型视图(Kruchten, 1995)(Chapter 2)

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

1) Scenarios: 场景(用例),从外界的角度描述系统建模出来的功能。这个视图必须描述系统支持做什么。所有的其它视图都依赖于从这个视图中得到该做什么的指导。这就是叫“4+1”视图的原因。 Scenarios典型地包含用例图,描述(descriptions),以及系统概览图(overview diagrams)。

2) Logic View: 逻辑视图用于系统各个部分的抽象描述,用于建模一个系统是如何组织起来的以及每个部分如何与其他部分交互。 逻辑视图包含的UML图包括类图、对象图、状态机图和交互图(interaction

diagrams)

3) Process View: 过程视图描述系统内部的过程,在观看系统内部发生了什么的时候它非常有用。

过程视图包含的UML:活动图

4) Deployment View: 描述系统的各部分如何组织成模块和组件。在管理系统内部的分层结构中非常有用。

典型地包含UML的组件图(component diagrams)

5) Physical View: 描述系统中与真实世界中相关的实体如何设计。它展示了抽象的系统的各个部分如何映射到最终部署的系统中。 典型地包含部署视图(deployment diagrams)

总结:逻辑视图和部署视图(原文CH2P56写成开发试图,疑误)描述系统的静态结构,进程视图和物理试图描述动态结构。

如何选择使用何种试图?? 1) Build a table.

? ROWS: Enumerate the stakeholders(风险承担者)

? COLUMNS: Enumerate the set of styles that could apply

? to the architecture being documented. This is our potential(潜在的)

set of views.

? Check box (x,y) if stakeholder x would like view y.

2) Combine views appropriately to reduce number.

3) Prioritize views based on need. (Some stakeholders may have extra weight.)

What languages and notations shall we use to record that information?

UML: 它不是设计来文档化体系结构信息的,但是它是事实上的标准语言。 ADL: Architecture description languages, has became an IEEE standard.

UML图

“4+1”视图与UML图的关系:

Use Case: 用于显示若干角色以及这些角色与系统提供的用例之间的连接关系。用例是系统提供的功能的描述。

Class diagram: 表示系统中的类和类与类之间的关系,它是对系统静态结构的描述

Object Diagram: 是系统在某一时间点的对象的快照,它展示的是实例和不是类,所以也叫实例图(instance diagram)。

Package Diagram: package is a grouping construct that allows you to take any construct in the UML and group its elements together into higher-level units. you can use packages for every other bit of the UML.

Sequence Diagram: 用来反映若干个对象之间的动态协作关系,也就是随着时间的推移,对象之间是如何交互的。

Communication Diagram: 描述对象间的协作关系,协作图(通信图)跟序列图相似,显示对象间的动态合作关系。如果强调时间和顺序,则使用序列图;如果强调上下级关系,则选择协作图。这两种图合称为交互图。

State diagram: 描述类的对象所有可能的状态以及事件发生时状态的转移条件。通常,状态图是对类图的补充

Activity Diagram: 描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动.

Component Diagram: 描述代码构件的物理结构及各构件之间的依赖关系 Deployment Diagram: 部署图定义系统中软硬件的物理体系结构.

Interaction Overview Diagram: Interaction overview diagrams are a grafting together of activity diagrams and sequence diagrams. You can think of interaction overview diagrams either as activity diagrams in which the activities are replaced by little sequence diagrams, or as a sequence diagram broken up with activity diagram notation used to show control flow.

Timing Diagram: Timing diagrams are another form of interaction diagram, where the focus is on timing constraints: either for a single object or, more usefully, for a bunch of objects.

5. Quality Attributes(Chapter 3)

6大质量属性是其外延

? Availability ? Modifiability ? Performance ? Security ? Testability ? Usability

Availability General Scenarios

Modifiability

Performance

Security

Testability

Usability

Quality Attribute Stimuli Quality Stimulus Attribute Availability Unexpected event, nonoccurrence of expected event Request to add/delete/change/vary functionality, platform, Modifiability quality attribute, or capacity Performance Periodic, stochastic, or sporadic Tries to display, modify, change/delete information, access, Security or reduce availability to system services Testability Completion of phase of system development Wants to learn system features, use a system efficiently, Usability minimize the impact of errors, adapt the system, feel comfortable

6. Architecture Patterns and Styles

Tactics(策略): An architectural tactic is a fine-grained(细粒度的) design approach used to achieve a quality attribute response. Tactics are the “building blocks” of design from which architectural patterns are created.

Availability tactics

Modifiability Tactics

performance tactics

Security Tactics

testability tactics

usability tactics

Architecting with Design Operators: Performance Design operators are a fundamental design tool for creating an architectural design.

? Decomposition (分解)

? Replication (复制/冗余(redundancy)) ? Compression (压缩) ? Abstraction (抽象)

? Resource Sharing(资源共享)

A. Decomposition: Decomposition is the operation of separating distinct functionality into distinct components that have well-defined interfaces(广泛用于工程设计领域). 它把一个系统分成两个或者更多的系统。用于打包一系列的质量属性包括可修改性,可移植性(portability),性能和可构建性(buildability) 分类:

部分/整体分解 泛化/特化分解

B. Replication: 冗余用于增强可靠性和性能。 分类:

冗余(Redundancy): where there are several identical copies of a component executing simultaneously

N-version programming: where there are several different implementations of the same functionality.

C. Compression: 意义上这是和分解近似相反的操作,意在改善性能。 D. Abstraction: 通过引入一个语义丰富的服务层来隐藏信息,同时隐藏实现的细节。同时也可以指创建一个虚拟机(JDBC/ODBC)。特点:增加适配性。 E. Resource Sharing: 封装数据或者服务以便让多个独立的客户端共享它们。特点:增加集成度(integrability),可移植性和可修改性

7. ADD: Attribute-driven Design(chapter 5)

定义:ADD is a step-by-step method for systematically producing the first architectural designs for a system.

ADD的结果:全部的结构决策、内部连接和协调机制、应用模式和策略制定各部分的机制、显式达到质量属性的要求、不能详细到接口!

ADD输入:质量属性需求、功能需求、约束。

ADD步骤:

1) 确定足够的需求信息 2) 选择系统的一部分分解

3) 优先部分需求以及标识架构驱动

4) 选择满足与所选择的系统分解向关联的那部分系统的架构驱动的设计概念:模式(patterns)、风格(styles)、策略(tactics) 5) 实例化(instantiated)架构元素,分配功能性需求 6) 归并(merge)设计完成 7) 分配剩下的功能性需求 8) 定义戒口给实例化元素

9) 检查和提炼需求,使他们能约束实例化元素 10) 对于系统的下一个分解部分,重复步骤2到9

8. 架构评估ATAM(Chapter 6)

SAAM: Scenario-based Architecture Analysis Method ATAM: Architecture Trade-off Analysis Method ATAM的目标:(Page 10~11, chapter 6)

1) 帮助投资者提出能够发现架构设计决策中潜在问题方法。

2) ATAM不提供精确的分析,它的目标是发现架构决策中的风险。

3) 我们需要找到一种趋势(trends),即架构决策和系统属性预测之间的关系

ATAM所带来的利益:(Page 12, chapter 6) 1) 标示风险

2) 阐明质量属性需求 3) 改进架构文档

4) 为架构决策准备好文档化的基础 5) 增进投资者(stakeholders)之间的通信 总结:改进架构。

ATAM阶段(Phases):(Page 13, chapter 6)

1) Phase 0: 这个阶段先于技术评估:客户和评估团队进行沟通并达成一致 2) Phase 1: 包括一小组主要面向技术的投资者。 特点

A. 以架构为中心

B. 聚焦于引出架构信息的细节并分析它 C. 自顶向下的分析方法 具体步骤:(1~6步)

① 提出(Present)ATAM ② 提出业务驱动 ③ 提出体系结构 ④ 标示架构方法

⑤ 生成质量属性实用树(Quality Attribute Utility Tree)

使用质量属性实用树来标示,排序以及体疗最重要的质量属性目标:

- 一棵实用树是一个自顶向下的使用工具,用来刻画和排序驱动属

性相关的需求

- 驱动质量属性是一些高级节点,如性能、可修改性、安全性和可

用性

- 场景是实用树的叶子

输出:指定的质量属性需求的描述(characterization)和排序(prioritization)

⑥ 分析架构方法

3) Phase 2: 包括一大组投资者。 特点:

A. 以投资者为中心

B. 聚焦于引出不同投资者的意见以及检验前一阶段的结果 步骤:上一阶段的步骤接下去:

① 头脑风暴和排序各个场景 ② 分析架构方法 ③ 提出结果

4) Phase 3: 产生一个最终的报告给客户,以及向上映射到评估质量和ATAM原料(materials)

本文来源:https://www.bwwdw.com/article/nkrx.html

Top