论软件架构评估

【提纲总结】

1. 摘要：项目背景，点题，使用了ATAM等

2. 开始：系统使用的技术以及系统整体架构介绍

3. 入题：提出架构评估，简述质量属性，和质量效用树的四个重要属性

4. 切题：简述所有的评估方式，场景评估分为SAAM、ATAM、CBAM，为何使用ATAM？

5. 具体开始：组建小组，人员，我的身份是，ATAM有哪四个阶段，描述、调查分析、测试、报告

6. 具体1：描述与介绍，介绍ATAM方法，大家讨论，最终使用什么架构，介绍子模块

7. 具体2：调查分析，大家提出注意那些质量属性，并得出质量效用树

8. 具体3：测试，集体讨论，得出四个质量属性的优先级，各自使用什么技术

9. 具体4：报告，最终形成评估报告，确定风险、敏感、权衡、非风险，形成哪些文档

10. 收尾：完工、好评、稳定运行、点题ATAM保证了系统完成

【摘要：项目背景，点题，使用了ATAM等】

xxxx年xx月，我公司承担了xxxx公司的xxxx系统的开发工作，我在该项目中承担系统架构设计师的职务，主要负责系统的架构设计工作。该项目的主要目的是xxxxxx。本文以xxxx项目为例，论述了软件系统的架构评估。整个系统采用了面向服务的SOA的架构设计方法。在架构设计完成之后，对软件架构评估采用了基于场景的评估方式中的体系结构权衡分析方法ATAM，并纤细描述了其评估过程，项目评估小组经过对项目的风险点、敏感点和权衡点的讨论后生成了质量效应树。目前系统已稳定运行一年多，从而验证了该项目采用ATAM架构评估保证了系统的顺利完成

详细介绍项目的背景，具体内容，使用的技术、方案，解决了什么问题。

【开始：系统使用的技术以及系统整体架构介绍】

系统采用了面向服务的架构SOA，前端使用xx技术，后端使用xx技术，数据库使用xx，服务器使用Linux服务器。拆分的子模块有，封装使用了什么，消息通信使用了xx，根据客户需求，我将系统拆分成了好几个子模块。

【入题：提出架构评估，简述质量属性，和质量效用树的四个重要属性】

架构评估是软开过程中的重要环节，在架构评估中的质量属性有，性能，可用性，可修改性，安全性、可靠性，功能性、互操作性，其中性能、可用性、可修改性、安全性等四个质量属性是质量效用树的重要组成部分。性能是指系统的响应能力，即经过多长时间对事件做出响应；可用性是指系统能够正常运行的时间比例，通过两次故障之间的时长或者发生故障后恢复正常的时长进行表示；可修改性是指系统能够以较高的性价比进行系统的修改的能力；安全性是指系统能够向合法用户提供服务，同时拒绝非授权用户使用或者拒绝提供服务的能力。

【切题：简述所有的评估方式，场景评估分为SAAM、ATAM、CBAM，为何使用ATAM？】

常用的架构评估方法有：基于问卷的评估方式、基于场景的评估方式和基于度量的评估方式。基于问卷的评估方式是指由多个评估专家通过问卷调查的方式回答问卷中的问题，对多个评估结果进行综合，最终得到结果，其评价具有主观性不太适合本项目；而基于度量的评估方式虽然评价比较客观，但是需要评估者对系统的架构有精确的了解，结合本项目的实际情况也不太适合。而基于场景的评估方式需要评估者对系统中等了解，评价比较主观，故本项目采用了基于场景的评估方式。基于场景的评估方式分为，架构权衡分析法ATAM、软件架构分析法SAAM和成本效益分析法CBAM。本项目中根据不同的质量属性使用了ATAM作为系统架构的评估方法。

【具体开始：组建小组，人员，我的身份是，ATAM有哪四个阶段，描述、调查分析、测试、报告】

在使用ATAM进行架构评估时，我们根据项目需要成立了评估小组，成员：小组负责人、项目决策者、架构设计师、用户、开发人员、测试人员、系统部署人员等项目干系人。我在这里面的身份是小组负责人以及架构设计师。架构的评估经历了描述阶段、调查分析阶段、测试阶段和报告阶段等四个阶段

【具体1：描述与介绍，介绍ATAM方法，大家讨论，最终使用什么架构，介绍子模块】

描述和介绍阶段：由于项目评估小组成员有部分对ATAM并不熟悉，我首先介绍了ATAM方法。它是一种基于场景的软件架构评估方法，对系统的多个质量属性基于场景进行评估。通过评估确认系统存的的风险，并检查各自的非功能性需求是否得到满足。大家都说了什么。。。最后最为架构师的我描述了系统采用SOA架构，并将系统进行了拆分，并讲解了各个子模块的功能，初步决定了系统服务端在Linux下使用xx语言开发

【具体2：调查分析，大家提出注意那些质量属性，并得出质量效用树】

调查分析阶段，不同的需求方基于各自的考虑都提出了各自的需求，其中客户提出可用性，开发人员提出可修改性，测试人员提出安全性，用户提出性能等，经过总结我们得出了系统的质量效用树

【具体3：测试，集体讨论，得出四个质量属性的优先级，各自使用什么技术】

测试阶段，经过评估小组的集体讨论，确定了不同场景的优先级如下，可用性最高，性能其次，可修改性和安全性次之，各个方面各自采用什么技术保障

【具体4：报告，最终形成评估报告，确定风险、敏感、权衡、非风险，形成哪些文档】

最后形成了评估报告，经过对架构的评估，确定了系统的风险点、敏感点、权衡点和非风险点，最后以文档的形式表现。包括架构分析方法文档、架构的不同场景以及各自的优先级、质量效用树、风险点决策、非风险点决策以及每次的评估会议记录。

【收尾：完工、好评、稳定运行、点题ATAM保证了系统完成】

该项目于 xxxx 年 xx 月完工，系统上线后取得了 xxxx 效果，得到了客户的一致好评，目前系统已稳定运行一年多，从而验证了该项目采用ATAM架构评估方式保证了系统的顺利完成

论软件系统架构风格

【提纲结构】

1. 摘要：项目背景、内容、我为架构师，主要负责架构设计等工作

2. 开始：具体介绍项目技术实现内容，底层采用了虚拟机风格中的解释器风格，数据分发层采用了独立构件风格中的隐式调用风格、整体采用了调用返回风格中的面向对象风格

3. 入题：项目开始时意识到架构风格的重要性，简化设计，加快进程、简述三种风格的内容，优缺点、为何选择它们？

4. 具体1：虚拟机风格的解释器风格的具体实现和效果

5. 具体2：独立构件风格中的隐式调用风格的具体实现和效果

6. 具体3：面向对象的具体操作和效果

7. 收尾：完工、好评、稳定运行，可控性，缺点有一个不痛不痒的，再接再厉

知识点：

1. 五大架构风格：数据流风格、调用-返回风格、独立构件风格、虚拟机风格、仓库风格

2. 数据流风格：面向数据流，按照一定的顺序从前往后依次执行；批处理以及管道-过滤器

– 二者的区别在于批处理前后构件不一定有关联，并且是作为整体传递，即必须前一个执行完才能执行下一个，管道-过滤器是前一个输出作为后一个的输入，前面执行到部分可以开始下一个的执行。

3. 调用返回风格：构件之间存在互相调用的关系，一般是显式调用；主子程序、面向对象、层次结构

– 面向对象：构件是对象，对象是抽象数据类型的实例，在抽象数据类型中，数据的标识和它们的相应操作被封装起来，对象的行为体现在其接收和请求的动作。连接件即使对象间交互的方式，对象是通过函数和过程的调用来交互的。

4. 独立构件风格：构件之间是互相独立的，不存在显式调用关系，通过事件触发异步执行；进程通信、事件驱动系统

– 隐式调用：构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程，它们之间的交互的连接件往往是以过程之间的隐式调用来实现的，主要优点是为软件复用提供了强大的支持，为构架你的维护和演化带来了方便；缺点是构件放弃了对系统计算的控制

5. 虚拟机风格：自定义一套规则供使用者使用，使用者基于规则开发构建，跨平台使用；解释器、规则系统

– 解释器：通常包括一个完成解释工作的解释引擎、一个包含被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，缺点是执行效率低；

– 基于规则的系统：包括规则集、规则解释器、规则-数据选择器和工作内存，一般用在人工智能领域和DSS中

6. 仓库风格：以数据为中心，所有的操作都围绕数据中心进行；

– 数据库系统：中央共享数据源、多个独立处理单元

– 黑板系统：知识源、黑板和控制；信号处理、问题规划和编译器优化等

– 超文本系统：一种非线性的网状信息组织方法，以节点为基本单位，链作为节点之间的联想式关联。互联网领域

论企业应用集成

【提纲结构】

1. 摘要：项目概述，我为架构师，点题：界面集成，数据集成，应用集成，过程集成

2. 开始：介绍项目背景，项目具体内容，为何要进行集成，各个子系统介绍

3. 入题：深知集成方法的重要性，详述用到的前三个集成方式的内容，相辅相成互为补充

4. 具体1：界面集成，某些仅需要展示的页面，界面改版，UI统一，添加菜单等方式

5. 具体2：数据集成，梳理数据，整合到一个中心数据库，整合统一，数据同步等

6. 具体3：应用集成，某些外部访问系统数据变动非常大，重新梳理需求，定义接口，重新开发，测试过程中，外部联调。难度极大，范围广，人员多，时间长。严格把控

7. 收尾：上线、验收、好评，由于外部系统众多，出现小部分异常，及时把控，好！

知识点：

1. 共有四个层次，界面集成、数据集成、应用集成、过程集成

2. 表示集成又称界面集成，这是比较原始和最浅层次的集成，但又是常用集成。这种方法把用户界面作为公共的集成点，把原有零散的系统界面集中在一个新的界面中。表示集成是黑盒集成，无需了解程序与数据库的内部构造。常用的集成技术主要有屏幕截取和输入模拟技术。表示集成通常应用于以下几种情况：

1. 在现有的基于终端的应用系统上配置基于PC端的用户界面

2. 为用户提供一个看上去统一，但是由多个系统组成的应用系统

3. 当只有可能在显示界面上实现集成时。表示集成的实现是很简单的，也是很不彻底的，只是做了一层“外装修”，而额外多出来的集成界面也将可能成为系统的性能瓶颈

3. 数据集成：为了完成控制集成和业务流程集成，必须首先解决数据和数据库的集成问题，在集成之前，必须首先对数据进行标识并编成目录，另外还要确定元数据模型，保证数据在数据库系统中分部和共享。因此，数据集成是白盒集成。有很多不同的中间件工具可以用于数据集成。例如，批量文件传输，即以特定的或是预定的方式在原有系统和新开发的应用系统之间进行文件传输；用于访问不同类型数据库系统的ODBC标准接口；向分布式数据库提供连接的数据库访问中间件技术等。通常在以下情况下，将会使用数据集成：

1. 需要对多种信息源产生的数据进行综合分析和决策

2. 要处理一些多个应用程序需要访问的公用信息库

3. 当需要从某数据源获得数据来更新另一个数据源时，特别是他们之间的数据格式不相同时。相对而言，数据集成比表示集成要更加灵活。但是，当业务逻辑经常发生变化时，数据集成就会面临困难

4. 控制集成：控制集成也称为功能集成或应用集成，是在业务逻辑层上对应用系统进行集成的。控制集成的集成点存在于程序代码中，集成处可能只需要简单的使用公开的API就可以访问，当然也可能需要添加附加的代码来实现，控制集成是黑盒集成。实现控制集成时，可以借助于远程过程调用或远程方法调用、面向消息的中间件、分布式对象技术和事务处理监控器来实现。控制集成与表示集成、数据集成相比，灵活性更高。表示集成和数据集成适用的环境下，都适用于控制集成。但是由于控制集成是在业务逻辑层进行的，其复杂度更高一些。而且，很多系统的业务逻辑部分并没有提供API，这样，集成难度就会更大。

5. 业务流程集成也称为过程集成，这种集成超越了数据和系统，它由一系列基于标准的、统一数据格式的工作流组成。当进行业务流程集成时，企业必须对各种业务信息的交换进行定义、授权和管理，以便改操作、减少成本、提高响应速度。业务流程集成不仅要提供底层应用支撑系统之间的互连，同时要实现存在于企业内部的应用之间，本企业和其他合作伙伴之间的端到端的业务流程的管理，它包括应用集成、B2B集成、自动化业务流程管理、人工流程管理、企业门户，以及对所有应用系统和流程的管理和监控等