科技小论文——课堂练习总结

科技小论文——课堂练习总结

潘攀达

(石家庄铁道大学)

摘  要：软件体系架构这门课让我获益匪浅，通过这门课使我学习到了很多行业中的重要思想以及相关专业知识。在学习的过程中，我们进行了一定量的课堂练习，以此来加强这方面知识的理解和掌握。这些练习设计到了以下几个方面——“架构的基本理解（什么是架构、为什么要出现架构、架构解决的是谁的问题）”、“软件体系结构六大质量属性（可用性、可修改性、性能、安全性、可测试性、易用性）”、“需求层次-需求方面二维矩阵”、“鲁棒图”、“架构分割”、“概念架构设计”、“逻辑架构设计”、“软件架构评估”、“SOA体系结构”等等。通过这些练习使得我对架构的概念有了较为深入的理解和掌握，同时能对架构进行分析和设计，并且在其中体现到六大质量属性。

关键词：SOA（面向服务的结构）；架构；质量属性；需求

Science and technology Essay -- Summary of classroom practice

Pan Panda

(Shijiazhuang Railway University)

Absrtact: the course of software architecture has benefited me a lot. Through this course, I have learned many important ideas and related professional knowledge in many industries. In the process of learning, we have carried out a certain amount of classroom exercises to strengthen the understanding and mastery of this knowledge. These exercises are designed in the following aspects: "basic understanding of Architecture (what is architecture, why architecture should appear, whose problems architecture solves)", "six quality attributes of software architecture (usability, modifiability, performance, security, testability, ease of use)", "two-dimensional matrix of requirement level requirement aspect", "robust diagram", etc“ Architecture segmentation, conceptual architecture design, logical architecture design, software architecture evaluation, SOA architecture, etc. Through these exercises, I have a more in-depth understanding and mastery of the concept of architecture. At the same time, I can analyze and design the architecture, which embodies six quality attributes.

Key words:SOA (Service Oriented Architecture); architecture; quality attributes; requirements

0 架构的认识

什么是架构？

经过我的阅读后，我了解到目前没有对架构的一个统一的定义，阅读之后我有了如下理解。

一个整体会有很多小任务要去做，这个整体同时也会包含很多个体。如果我们能把整体需要做的种种任务进行划分，划分之后把每块任务一一分配给擅长此任务的个体，个体高效地完成这项任务。而个体之间也会有信息的交流使得彼此之间能有联系体现出一个整体的概念，就像是一个大型机器里的无数个齿轮一样，共同运转，负责各自的任务，在一起便实现了一个大机器的任务。

以上就是我对架构的理解。

为什么要出现架构?

架构的产生有诸多原因，以下说出我阅读后的理解。

沿用我上面说到的整体和个体完成任务的关系。组成这个整体的每个个体所能完成的任务以及完成某些任务的效率是不一样的，因此我们需要对整体需要的大任务进行划分，并且将每块小任务分配给适合完成此项任务的个体，这样会提高总任务完成的效率。也即是，当我们对质量和效率有了更高的要求时，架构便会如上所述的产生了。

架构解决谁的问题？

通过阅读架构漫谈第三篇，我对这个问题有了如下认识。

上述问题换个问法便是，做的架构要解决的问题的主体是什么。可以明确，一个架构要解决的问题一定都是人的问题。比如妈妈让我去买酱油，“买酱油”实际上是一个解决方案，而不是问题，真正的问题是“我们家的人吃饭需要酱油，而我们家没有酱油了”。因此，解决的都是“人”的问题。

以下通过一个家庭的实例对架构进行认识。

（1）介绍家庭成员。

儿子、爸爸、妈妈。

（2）介绍家庭业务（例如做饭、洗衣、打扫卫生、刷碗等一系列业务）。

 做饭；洗衣服；打扫卫生；刷碗。

（3）介绍谁执行什么业务、怎么做，如何评价业务的效果，评价的标准是什么？

妈妈爸爸做饭、“洗菜、炒菜、蒸米饭”、通过家人吃饭的反馈来评价业务；

爸爸洗衣服、“通过洗衣机洗衣服”、通过晾干后的干净程度来评价业务；

儿子打扫卫生和刷碗、“手动打扫卫生、手动刷碗”、通过家人的卫生程度反馈来评价业务。

（4）各项业务触发的条件。

到饭点触发做饭；到了晚上触发洗衣服；吃饭完触发洗碗；到了晚上触发打扫卫生。

代码建模：

①模型类：创建一个family（家中各项业务定义成为方法，家庭成员作为变量）。

②执行类：familyView 是一个把家庭业务执行的视图类（例如做完饭后输出结果 “谁做的饭，做得什么饭”）。

③控制类：familyController，显示是负责存储数据到family对象中的控制器类，并相应地更新视图familyView，即指派谁执行相应的业务，业务之间的关联关系（例如做饭、刷完之间的前后关联关系）。

1 质量属性

架构的基本需求主要是在满足功能属性的前提下，关注软件质量属性，架构设计则是为满足架构需求（质量属性）寻找适当的“战术”。软件属性包括功能属性和质量属性，但是，软件架构（及软件架构设计师）重点关注的是质量属性。因为，在大量的可能结构中，可以使用不同的结构来实现同样的功能性，即功能性在很大程度上是独立于结构的，架构设计师面临着决策（对结构的选择），而功能性所关心的是它如何与其他质量属性进行交互，以及它如何限制其他质量属性。

质量属性被定义为：一个系统的用来描述系统满足利益相关者需求的程度的可测量或可测试的属性。质量属性亦被称为非功能性需求和跨职能约束，我将其理解为，质量属性与系统具体功能无关，一个系统质量属性会约束多个系统功能。软件架构被定义为：有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。系统的各个重要组成部分及其关系构成了系统的架构，这些组成部分可以是具体的功能模块，也可以是非功能设计与决策，他们相互关系组成一个整体，共同构成了软件系统的架构。一般来说，除了当前的系统功能需求外，软件架构设计过程中还需要关注可用性、可修改性、性能、安全性、可测试性、易用性等六个方面的质量属性，并且还需要平衡这六个方面的关系以实现需求和架构目标，也可以通过观察这些质量属性来衡量一个软件架构设计的优劣，判断其是否满足期望。

2 质量属性应用

2.1 可用性

可用性是指系统正常工作的时间所占的比例。可用性会遇到系统错误，恶意攻击，高负载等问题的影响。对于大型软件系统而言，服务不可用是一个重大事故，任何系统都不可能达到完全可用，总会有一些故障时间，扣除这些故障时间，就是系统的总可用时间。以大型网站为例，网站使用的服务器硬件通常是普通的商用服务器，这些服务器的设计目标本身并不保证高可用，也就是说很有可能会出现服务器硬件故障，因此网站高可用架构设计的前提是必然会出现服务器宕机，而高可用设计的目标就是当服务器宕机的时候，服务或者应用依然可用。网站高可用的主要手段是冗余，应用部署在多台服务器上同时提供访问，数据存储在多台服务器上互相备份，任何一台服务器宕机都不会影响应用的整体可用，也不会导致数据丢失。

衡量一个系统架构设计是否满足高可用的目标，就是假设系统中任何一台或者多台服务器宕机时，以及出现各种不可预期的问题时，系统整体是否依然可用。

2.2 可修改性

作为软件开发人员来说频繁的更改需求是一件痛苦的事情，为什么痛苦呢？一方面来自于需求的更迭，另一方面也跟我们对软件的合理架构密不可分，一个合理的软件架构足够应付需求的未知变化，这体现了软件的可修改性。在考虑软件的可修改性上作出的架构很大程度上将减少需求更迭给我们带来的“痛苦”。

可修改性主要关注两方面的问题，可以修改什么，何时以及谁进行修改。它可理解为：指系统或软件的能够快速地以较高的性价比对系统进行变更的能力。比如说：开发人员想修改用户界面。那当我们对界面进行修改时是否会引起对另一个模块的影响，是否会引起后台控制，业务逻辑代码的变更，是否会引起整个网站的崩溃等副作用的变化，这体现了一个网站的整个架构的是否具备可修改性。

2.3 性能

性能是指系统的响应能力----即对外部刺激(事件)做出反应时所需要的时间或在某段时间内所处理的事件个数。性能是衡量一个系统的重要指标，比如12306在春运期间因为人流量过大而响应缓慢乃至崩溃，一个响应缓慢的系统会导致严重的用户流失，很多时候，系统的性能问题时触发系统架构升级优化的触发器。性能是架构设计的一个重要方面，任何软件架构设计方案都必须考虑可能会带来的性能问题。可以通过改善算法，引入并发，分配不同任务不同优先级等来提高性能。

在架构设计中，必须考虑系统在高并发访问情况下，超出负载设计能力的情况下可能会出现的性能问题。若系统需要长时间持续运行，则还必须保证系统在持续运行且访问压力不均匀的情况下保持稳定的性能特性。

2.4 安全性

安全性是衡量系统在向合法用户正常提供服务的情况下，阻止非授权使用的能力。

考虑软件系统安全通常的流程先要分析潜在会有哪些 威胁；制定威胁的列表，评估它们并设定优先级；针对威胁进行分类；根据威胁选择安全的技术；最后设计对应的安全 服务。

在进行安全性方面的架构设计时，我们通常可以考虑采用成熟的安全系统（第三方硬件/软件）；以“小人之心”揣度输入的数据，从入口处要进行严格检查；要认识到，外部系统总是不安全的，并在设计时减少外部接口；对用户或者角色进行最小授权，不要让授权泛滥；缺省状态下也要使用安全模式，例如论坛系统，即使用户还没有登录，就分配其 Guest （游客）身份，以便今后统一管理；从 STRIDE1 方面进行 思考；最后要在管理上保护好系统，例如制定相关的规章制度，对服务器所在的机房进行严格的管理。需要做的安全架构总而言之就是保护系统不受恶意访问和攻击保护网站的重要数据不被窃

2.5 可测试性

可测试性指通过测试揭示软件缺陷的难易程度。测试是软件开发过程中很重要的一部分，会占用大量的时间和人力。如果想要高效的测试和获得高质量的软件产品，我们必须在软件项目的启动初期就开始关注软件质量。

从架构设计的角度来看，软件架构是系统设计和开发的核心，是系统设计师在充分分析最终用户的要求、开发组织、现有的技术水平的限制等因素的基础上，根据自己的开发经验而作出的系统初步框架。架构不是强调组成系统的单个元素，而是元素之间的安排及其相互关系。软件架构设计对于能否形成恰当的体系结构和达到系统的预期目标尤其重要。所以，在软件设计的早期阶段更应该强调架构设计的重要地位。在形成整个软件的逻辑模型的设计阶段，应该把架构设计作为主要的工作。只有运用合适的软件构架设计，才能设计出目标明确、功能完善的软件系统，以保证软件的可测试性和开发过程的顺利进行。

2.6 易用性

易用性关注的是对用户来说完成某个期望任务的难易程度。软件系统开发完之后，用户是否能较为容易地  理解其界面从而快速上手，掌握其操作以完成工作，并学习系统中所包含的其它的辅助的功能，提高工作效率。 例如，我们要为小学生用户开发一款产品，以帮助他们削铅笔。那么，专用刀片就没有卷笔刀来得好，它将专用的 刀片隐藏在塑料的模子里面，方便学生使用，并同时保证了安全。

总之就是架构设计过程中始终考虑到让软件系统易见、易学、易用。以技术为基础，以用户的体验为中心，提升软件易用性和界面友好性。