1、软件体系结构与设计,浙江大学城市学院周苏 教授QQ：81505050,第1章 概 述,第1章 概 述,关于软件工程原则指导实践的核心原则指导框架活动的原则什么是软件体系结构体系结构的描述与决策体系结构的研究范畴体系结构的设计原则,随着软件系统的规模和复杂性不断增加，系统的全局结构设计和规划变得比算法的选择以及数据结构的设计更加重要。软件工程师需要一种更好的视角来理解软件，并试图找到一种新的方法来构建更复杂的大型软件系统，这时，软件体系结构就被从软件设计中抽象出来，逐渐自然演化形成了一门新的学科。,第1章 概 述,软件系统的全局结构设计和规划问题包括全局组织结构、全局控制结构、通信和同步以及数据
2、存取的协议、规定设计元素的功能与组合、物理分布、规模和性能、演化的维度、设计方案的选择等，这些都是软件体系结构所关注的问题。如今，有效的软件体系结构及其明确的表示和设计已经成为软件工程领域的主导主题之一。,第1章 概 述,1.1 关于软件工程原则,一般来讲，软件工程实践是软件工程师日常使用的概念、原则、方法和在整个软件过程中所使用的开发工具的集合。在实践过程中，将利用由必要技术和管理所组成的软件过程模型，以保证软件开发的顺利开展。人们常说，软件开发知识的半衰期 为3年，即：你现在需要知道的那些知识，在三年内其中将有一半会过时。诚然，在技术相关的知识领域内，这种说法可能是正确的。但是，还有另一种
3、软件开发知识，即所谓“软件工程原则”并非如此。对于专业程序设计人员来说，这些软件工程原则有益于其整个职业生涯。,1.1 关于软件工程原则,McConnel 指出：软件工程知识体（大约在2000年）已经演变为“稳定的核心”，该知识体中包含了大约“开发一个复杂系统所需的75知识”。这个“稳定的核心”提供从软件工程模型、方法及工具中得来的，可以应用和评价的基本原理，是指导软件工程师工作的基本概念和核心原则。,1.1 关于软件工程原则,软件工程是一种层次化的技术（如图1-1所示）。任何工程方法（包括软件工程）必须构建在质量承诺的基础之上。全面质量管理、六西格玛和类似的理念。促进了不断的过程改进文化，正
4、是这种文化，最终引导人们开发更有效的软件工程方法。支持软件工程的根基在于质量关注点（quality focus）。,图1-1 软件工程的层次,1.1 关于软件工程原则,软件工程的基础是过程（process）层。软件过程将各个技术层次结合在一起，使得合理、及时地开发计算机软件成为可能。过程定义了一个框架，构建该框架是有效实施软件工程技术必不可少的。软件过程构成了软件项目管理控制的基础，建立了工作环境以便于应用技术方法、提交工作产品（模型、文档、数据、报告、表格等）、建立里程碑、保证质量及正确管理变更。,1.1 关于软件工程原则,软件工程方法（method）为构建软件提供技术上的解决方法（“如何做
5、”）。方法覆盖面很广，包括沟通、需求分析、设计建模、编程、测试和技术支持。软件工程方法依赖于一组基本原则，这些原则涵盖了软件工程所有技术领域，包括建模和其他描述性技术等。,1.1 关于软件工程原则,软件工程工具（tool）为过程和方法提供自动化或半自动化的支持。这些工具可以集成起来，使得一个工具产生的信息可被另外一个工具使用，这样就建立了软件开发的支撑系统，称为计算机辅助软件工程（computer-aided software engineering）。虽然每个软件工程项目是不同的，但却有着通用的普遍原则和一些与项目或产品无关的适用于每个过程框架活动的实践任务。,1.2 指导实践的核心原则,软
6、件工程以一系列核心原则为指导，这些核心原则为应用具有重大意义的软件过程以及执行有效的软件工程方法提供了帮助。在过程级上，核心原则建立了哲学基础从而指导软件开发团队执行框架活动和普适性活动、引导过程流以及生产一系列软件工程产品。在实践级，核心原则建立了一系列价值和规则，为分析问题、设计解决方案、实现和测试解决方案以及最终为用户部署软件提供指导。,1.2 指导实践的核心原则,跨越软件工程过程和实践的通用原则主要是： 为最终用户提供价值， 保持简洁， 维护可见的东西（产品和计划）， 认识（必须理解别人将消费你所生产的产品）， 面向未来， 计划复用，以及 认真思考。,1.2.1 指导过程的原则,在软件
7、过程中，许多不同的过程模型不论该模型是线性的、迭代的、传统的或敏捷的都可以用普遍适用的普通过程框架来描述。下面这组核心原则能够适用于这些框架，并延伸至每一个软件过程。原则1：敏捷。所选择的过程模型是否是传统的或敏捷的，敏捷开发的基本原则会提供判断的方法。所做工作的每一方面都应着重于活动的经济性保持技术方法尽可能简单，保持工作产品尽可能简洁，无论何时尽可能根据具体情况做出决定。原则2：每一步都关注质量。每个过程活动、动作及任务的出口条件应关注所生产的工作产品质量。,1.2.1 指导过程的原则,原则3：做好适应的准备。当需要的时候，应该让方法适应于由问题、人员以及项目本身施加的限制。原则4：建立一
8、个有效的团队。软件工程过程和实践是重要的，但最根本的还是人。必须建立一个彼此信任和尊重的自组织团队。原则5：建立沟通和协调机制。项目失败是由于遗漏重要信息，以及（或者）利益相关者未能尽力去创造一个成功的最终产品。这些属于管理的问题，必须设法解决。原则6：管理变更。必须建立一种机制来管理变更要求的提出、评估、批准以及实施的方式，其方法可以是正式的或非正式的。原则7：评估风险。在进行软件开发时可能会出现一些问题，因此，建立应变计划是非常重要的。,1.2.1 指导过程的原则,原则8：创造能给别人带来价值的工作产品。只创建那些能为其他过程活动、动作或任务提供价值的工作产品。每一个工作产品都作为软件工程
9、实践的一部分传递给别人，需求功能和特征表会传递给开发设计的人员，设计会传递给编码的人，等等。一定要确保工作产品所传达的是必要信息，不会模棱两可或丢失。,1.2.2 指导实践的原则,软件工程实践有一个最重要的目标按时交付包含了满足所有利益相关者要求的功能和特性的高质量、可运行软件。为此，必须采用一系列核心原则来指导技术工作，这些原则不考虑所使用的分析方法和设计方法、所使用的构建技术（例如程序设计语言、自动工具），或者所选用的验证和确认方法。以下列举的一组核心原则是软件工程实践的基础。,1.2.2 指导实践的原则,原则1：分治策略（分割和攻克）。更具技术性的表达方式是：分析和设计中应经常强调关切问
10、题分解（SoC，Separation of Concerns）。一个大的问题分解为一组小的元素（或关切问题）之后就比较容易求解。从概念上讲，每个关切问题都传达了可以开发、在某些情况下可被确认的特定功能，这与其他关切问题是无关的。原则2：理解抽象的使用。抽象就是对系统中一些复杂元素的简单化，用以传达词组的含义。我使用抽象报表，是假设你可以理解什么是报表，报表表示的是目录的普通结构，可以将经典的功能展示其中。在软件工程实践中，可以使用许多不同层次的抽象，通常从高度抽象的模型开始（例如报表），然后逐渐将这些模型提炼成较低层次的抽象（例如专栏或SUM功能）。,1.2.2 指导实践的原则,抽象的意图是减
11、弱交流细节的需求。但有时，由于细节的“渗漏”，有问题的影响会不期而至。由于对细节不了解，所以对问题产生的原因并不容易分析。原则3：力求一致性。是否创建一个需求模型、开发一个软件设计、开发源代码、或者创建测试用例，一致性原则建议熟悉的上下文使软件易于使用。例如，为WebApp（指基于Web的系统和应用）设计一个用户界面一致的菜单选择、一致的彩色设计的使用，以及可识别的图标的一致性使用，都有助于使界面在人体工程学方面更为合理。,1.2.2 指导实践的原则,原则4：关注信息传送。软件所涉及的信息传送是多方面的从数据库到最终用户、从现有的应用系统到WebApp、从最终用户到图形用户界面（GUI）、从操
12、作系统到应用问题、从一个软件构件到另一个构件。每一种情况，信息都会流经界面，就有可能出现错误、遗漏或者歧义的情况。这一原则的含义是必须特别注意界面的分析、设计、构建以及测试。,1.2.2 指导实践的原则,原则5：构建能展示有效模块化的软件。对重要事务的分割（原则l）建立了软件的哲学。模块化提供了认知这一哲学的机制。任何一个复杂的系统都可以被分割许多硬块（构件），但好的软件工程实践还要求模块必须是有效的。也就是说，每个模块都应该专门地集中表示系统的一个良好约束的方面其功能具有内聚性和（或）局限于所表示的内容范围。另外，模块应当以相对简单的方式关联起来每个模块应同其他模块、数据源以及环境方面是低耦
13、合的。,1.2.2 指导实践的原则,原则6：寻找模式。模式的目标是建立一个典集，帮助开发者解决整个软件开发过程中反复出现的问题。模式还有助于创建一种共同语言，交流有关这些问题及其解决办法的见解和经验。对这些解决办法以及它们之间关系的正式地编纂成典，可以使我们成功地捕获知识体系，这一知识体系中明确了对满足用户需求的良好体系结构的认识。原则7：在可能的时候，用大量不同的观点描述问题及其解决方法。当对一个问题及其求解方法从大量不同的观点进行描述时，就很有可能获得更深刻的认识，发现错误和遗漏。例如，需求模型可以用面向数据、面向功能或者面向行为的观点来陈述，每个观点都提供了一个对问题及其需求的不同看法。
14、,1.2.2 指导实践的原则,原则8：记住：有人将要对软件进行维护。从长期看，缺陷暴露出来时软件需要修正；环境发生变化时软件需要适应；利益相关者需要更多功能时软件需要增强。如果可靠的软件工程实践能够贯穿于整个软件过程，就会便于这些维护活动的实施。虽然上述原则不能包含构建高质量软件所需要的全部内容，但它们为软件工程方法奠定了基础。,1.3 指导框架活动的原则,在很多情况下，所讨论的每个通用框架活动的原则都是处于抽象的低层次的核心原则。核心原则集有助于有意义的软件过程的应用以及有效的软件工程方法的执行。,1.3.1 沟通原则,在分析、建模或规格说明之前，客户的需求必须通过沟通活动来收集，客户有一些
15、问题适合于使用计算机求解，软件人员就要对客户请求做出响应。沟通从开发者对客户提出的需求做出回应之时就开始了。高效的沟通（与其他技术人员的沟通、与客户和其他利益相关者的沟通、与项目经理的沟通）是一个软件工程师所面临的最具挑战性的工作。,1.3.1 沟通原则,与客户沟通（以及软件项目内部的沟通）的主要原则包括：原则1：倾听。注意仔细倾听讲话者的每一句话，而不是急于叙述你对这些话的看法。如果有什么事情不清楚时可以要求他澄清，但要避免经常打断别人的讲述。原则2：有准备的沟通。在与其他人碰面之前花点时间去理解问题。如果必要的话，做一些调查来理解业务领域的术语。如果负责主持一个会议，那么在会前应准备一个议
16、事日程。原则3：沟通活动需要有人推动。沟通会议应该有一个主持人（推动者），其作用是： 保持会议向着有效的方向进行； 调解会议中所发生的冲突； 确保遵循沟通原则。,1.3.1 沟通原则,原则4：最好当面沟通。此外，如果能把一些相关信息写出来，通常可以使工作做得更好，例如可以在集中讨论中使用草图或文档草稿。原则5：记笔记并且记录所有决定。任何解决方法都可能有缺陷，参与交流的人应该记录下所有要点和决定，以备后用。原则6：保持通力协作。当项目组成员的想法需要汇集在一起，用以阐述一个产品或者某个系统的功能或特征的时候，就产生了协作与协调的问题。每次协作都可能建立起项目成员间的相互信任，并创建一致的目标。
17、,1.3.1 沟通原则,原则7：把讨论集中在限定的范围内。在交流中，参与的人越多，话题转移到其他地方的可能性就越大。最简便的方法就是保持谈话模块化，只有当某个话题完全解决之后再开始别的话题（不过还应该注意到原则9）。原则8：如果某些内容很难表述，可考虑采用图形表示清楚。语言沟通的效果很有限，当语言无法表述某项工作的时候，草图或者绘图通常可以让表述变得更为清晰。原则9：a）一旦认可某件事情，转换话题；b）如果不认可某件事情，转换话题；c）如果某项特性或者功能不清晰，当时无法澄清，转换话题。交流如同所有其他活动一样需要时间，与其永无止境地迭代，不如让参与者认识到还有很多话题需要讨论（参见原则2），
18、“转换话题”有时是达到敏捷交流的最好方式。,1.3.1 沟通原则,原则10：协商不是一场竞赛或者一场游戏，双赢时才发挥了协商的最大价值。很多时候软件工程师和利益相关者必须商讨一些问题，如功能和特征、优先级和交付日期等。若要团队合作得很好，那么各方要有一个共同的目标，并且谈判还需要各方的协调。在开发者与客户进行沟通时，客户沟通原则主要着眼于两点：减少争吵和扩大双方的交流广度，双方必须互相协作以更好地交流。,1.3.2 策划原则,沟通活动可以协助软件开发团队定义其全局目标（即主题，当然这会随着时间的推移而变化）。可是，理解这些目标与为达到这些目标而制定计划并不是一回事。策划活动包括一系列管理和技术
19、实践，可以为软件开发团队定义一个便于他们向着战略目标和战术目标前进的路线图。不管我们做多少努力，都不可能准确预测软件项目会如何进展。也不存在简单的方法来确定可能遇到的不可预见的技术问题，在项目后期还有什么重要信息没有掌握，以及会出现什么误解，或者会有什么商务问题发生变化。然而，软件团队还是必须制定计划。,1.3.2 策划原则,有很多不同的制定计划的方法。一些人认为变化常常会消除详细计划的必要性；另一些人却认为计划提供了有效的路线图，并且计划得越详细，团队损失的可能性就越小；也有一些人认为快速制定计划是必需的，而路线图将会在真正的软件开发工作开始时浮现出来。,1.3.2 策划原则,在许多项目中，
20、“过度计划”是一种时间的浪费并且是在做无用功（因为事物有太多的变化），但是“最起码的计划”是制止混乱的良方，适度执行计划足以为团队提供有用的指导，但无论多么严格地制定计划，都应该遵循以下原则：原则1：理解项目范围。范围可以为软件开发团队提供一个准确的目的地。原则2：吸收利益相关者参与策划。利益相关者（干系人）能够限定一些优先次序，确定项目的约束。为了适应这种情况，软件工程师必须经常商谈交付的顺序、时间表以及其他与项目相关的问题。,1.3.2 策划原则,原则3：计划的制定应按照迭代方式进行。项目计划不可能一成不变。工作开始后，有很多事情有可能会改变，那么计划就必须调整以适应这些变化。另外，迭代式
21、增量过程模型指出了要根据用户反馈的信息（在每个软件增量交付之后）重新制定计划。原则4：基于已知的估计。估计的目的是基于项目组对将要完成工作的当前理解，提供一种关于工作量、成本和任务工期的指标。如果信息是含糊的或者不可靠的，估计也将是不可靠的。原则5：计划时考虑风险。如果团队已经明确了哪些风险最容易发生且影响最大，那就应该制定应急计划。另外，项目计划（包括进度计划）应该可以调整以适应那些可能发生的风险。,1.3.2 策划原则,原则6：保持脚踏实地。人们不能每天每时每刻都工作。噪音总能侵入人们的交流之中，生活常常会有疏忽与含糊，变化总是在发生，甚至最好的软件工程师都会犯错误。这些现实的东西都应该在
22、项目制定计划的时候加以考虑。原则7：调整计划粒度。粒度是指项目计划细节的精细程度。一个“细粒度”的计划可以提供重要的工作任务细节，这些细节是在相对短的时间段内计划完成的（这样就常常会有跟踪和控制的问题）。一个“粗粒度”的计划提供了更宽泛的长时间工作任务。通常，粒度随项目的进行而从细到粗。在几个星期或几个月的时间里可以详细地策划项目，而在几个月内都不会发生的活动则不需要细化（太多的东西将会发生变化）。,1.3.2 策划原则,原则8：制定计划确保质量。计划应该有利于软件开发团队如何确保开发的质量。如果要执行正式技术评审的话，应该将其列入进度；如果在构建过程中用到了结对编程, 那么在计划中要明确描述
23、。原则9：描述如何适应变化。即使最好的策划也有可能被无法控制的变化破坏。软件开发团队应该确定在软件开发过程中一些变化需要怎样去适应，例如，客户会随时提出变更吗？如果提出了一个变更，团队是不是要立即去实现它？变更会带来怎样的影响和开销？,1.3.2 策划原则,原则10：经常跟踪并根据需要调整计划。需要每天都追踪项目计划的进展，找出计划与实际执行不一致的问题所在，当任务进行出现延误时，计划也要随之做出调整。最高效的方法是软件开发项目组所有成员都参与到策划活动中来，只有这样，项目组成员才能很好地认可所指定的计划。策划的原则是着眼于为了使整个系统或产品的开发沿着最佳路线前进提供指导。计划可以只是为某个
24、软件增量而设计，或者也可以为整个项目而制定。无论如何，计划都必须涉及要做什么，谁来完成以及什么时候完成。,1.3.3 建模原则,可以通过创建模型来更好地理解所需要构建的实体。当实体是物理实物（例如：一栋建筑、一架飞机、一台机器）时，可以构建在实物模型上。可是，当实体是一个软件的时候，模型就是另外一种形式了。它必须能够表现出软件所转换的信息、使转换发生的架构和功能、用户要求的特征以及转换发生时系统的行为模型。必须能在不同的抽象层次下完成那些目标首先从客户的角度描述软件，然后在更侧重于技术方面表述软件。,1.3.3 建模原则,在软件工程中要创建两类模型，即需求模型和设计模型。需求模型（也称为分析模
25、型）通过在信息域、功能域和行为域中描述软件来表达客户的需求。设计模型表述了可以帮助开发者高效开发软件的特征，即架构、用户界面以及构件细节。,1.3.3 建模原则,1. 敏捷模型建模原则下面的系列建模原则有助于使用敏捷模型的软件工程师执行建模活动和任务：原则1：主要目标是构建软件而不是创建模型。敏捷的意义是尽可能快地将软件提供给用户。可以达到这个目标的模型是值得软件团队去构建的，但是，需要避免那些降低开发过程的速度以及不能提供新的见解的模型。原则2：不要创建任何不需要的模型。变化发生时，创建的模型必须是最新的。更重要的是，每创建一个新模型所花费的时间，还不如花费在构建软件上（编码或测试）。因此，
26、只创建那些可以使软件的构建更加简便和快速的模型。,1.3.3 建模原则,原则3：尽量创建能描述问题和软件的最简单模型。不要建造过于复杂的软件。保持模型简单，则产生的软件必然也会简单，使得软件易于集成、易于测试，也易于维护（对于变更）。另外，简单的模型也易于开发团队成员的理解和评判。原则4：用能适应模型改变的方式构建模型。需求发生变化，就需要迅速改变需求模型。所带来的问题是如果没有相当完整的需求模型，所创建的设计（设计模型）常常会丢失重要功能和特性。原则5：明确描述创建每一个模型的目的。每次创建模型，都问一下为什么这么做。如果不能为模型的存在提供可靠正当的理由，就不要再在这个模型上花费时间。,1
27、.3.3 建模原则,原则6：调整所开发模型来适应待开发系统。或许需要使模型的表达方式或规则适用于应用问题；例如，一个视频游戏应用所需要的建模技术与实时的、嵌入式控制汽车引擎的软件所需的建模技术完全不同。原则7：构建有用而不是完美的模型。当构建需求模型和设计模型时，软件工程师要达到减少返工的目的。也就是说，努力使模型绝对完美和内部一致并不值得。对当前建模工作的管理要始终考虑到软件工程下一步骤的实施。无休止地使模型“完美”不能满足敏捷的要求。,1.3.3 建模原则,原则8：模型的构造方法不要过于死板。如果模型能够成功地传递信息，那么表述形式是次要的。虽然软件团队的每个人在建模期间都应使用一致的表达
28、方式，但模型最重要的特性是交流信息，以便软件工程执行下一个任务。如果一个模型可以成功地做到这一点，不正确的表达方式可以忽略。原则9：相信直觉。如果你是个有经验的软件工程师，就应相信自己的直觉。如果有些事情告诉你所设计的模型注定会失败（尽管不能明确地证明），你有理由再花一些时间来检查模型或开发另一个模型。原则10：尽可能快地获得反馈。每个模型都应经过软件团队的评审。评审的目的是为了提供反馈，用于纠正模型中的错误、改变误解，并补充不经意遗漏的功能和特性。,1.3.3 建模原则,2. 需求建模原则如今，已经开发出了大量的需求建模方法，研究人员弄清了需求分析中的问题及其出现原因，也开发出了各式各样的建
29、模表达方法以及相关启发性解决方法。每一种分析方法都有其独立的观点。不过，所有的分析方法都具有共同的操作原则，通过应用这些原则，软件工程师可以系统地解决问题：,1.3.3 建模原则,原则1：必须描述并理解问题的信息域。信息域包括了流入系统的数据（从最终用户、其他系统或者外部设备）、流出系统的数据（通过用户接口、网络接口、报告、图形以及其他方式）以及那些收集和组织永久性数据对象的数据存储（例如：永久存储的数据）。原则2：必须确定软件所要实现的功能。软件功能直接为最终用户服务，并且为用户可见的特征提供内部支持。一些功能对流入系统的数据进行转换。在其他情况下，有些功能在某种程度上影响着对软件内部过程或
30、外部系统元素的控制。功能可以以不同的抽象层次描述，这些抽象层次从对目标的笼统陈述到对那些必不可少的过程细节的描述。,1.3.3 建模原则,原则3：必须描述软件的行为（作为外部事件的结果）。软件的行为受到与外部环境交互的驱动。最终用户提供的输入，由外部系统提供的控制数据，或者通过网络收集的监控数据都会引起软件的特定行为。原则4：描述信息、功能和行为的模型必须以一种能揭示分层细节的方式分解开来。需求建模是解决软件工程问题的第一步。它能使开发者更好地理解问题并且为确定解决方案（设计）准备条件。复杂的问题很难完全解决，基于这样的原因，可以使用“分而治之”的战略。把大的复杂问题划分成很多易于理解的子问题
31、，即“分解”的概念，这也是分析建模的关键策略。,1.3.3 建模原则,原则5：分析任务应该从本质信息转向实现细节。需求建模从最终用户角度描述问题开始。在没有考虑解决方案的前提下描述问题的“本质”。例如，一个视频游戏需要玩家在他所扮演角色进入一个危险的迷宫时控制其角色行动的方向，这就是问题的本质。实现细节（通常作为设计模型的一部分来描述）指出问题的本质将如何实现，对于视频游戏来说，可能需要用到语音输入。或者采用另一种办法，键入键盘命令，或者朝某个特定方向移动操纵杆（或者鼠标），或者在空中挥舞动作感应设备等。,1.3.3 建模原则,3. 设计建模原则通常，建筑师的房屋设计方案首先表达所有需要建造的
32、东西（例如，房屋的三维透视图），然后逐渐进行细化，为构建各个细节（例如，管线分布）提供指导。类似地，软件设计模型为系统提供了各式各样的不同视图。,1.3.3 建模原则,已经有许多方法可以导出各种软件设计的要素。例如数据驱动方法，通过数据结构来得到程序构架和最终的处理构件；模式驱动方法，就是使用问题域（需求模型）信息来开发架构风格和处理模式；面向对象方法，使用问题域对象来驱动创建数据结构以及操作这些数据结构的方法。但无论使用什么方法，都使用同样的设计原则。,1.3.3 建模原则,原则1：设计可追溯需求模型。需求模型描述了问题的信息域、用户可见的功能、系统的行为以及一套需求类，该需求类把业务对象和
33、为这些对象服务的方法结合在一起。设计模型将这些信息转化为系统架构、一套实现主要功能的子系统以及一套实现需求类的构件。设计模型的各个元素都应该能追溯到需求模型。原则2：始终关注待建系统的架构。软件架构是待建系统的骨架，它决定着系统接口、数据结构、程序控制流和行为、测试的方法以及在建系统的可维护性等。因此，设计应该从考虑架构开始，在架构确定之后再开始考虑构件级设计。,1.3.3 建模原则,原则3：数据设计与功能设计同等重要。数据设计是架构设计的基本要素。在设计中不能忽略数据对象的实现方法。一个结构良好的数据设计可以简化程序流程，让软件构件设计与实现变得更简单，使得整个处理过程更为高效。原则4：精心
34、设计接口（包括内部和外部接口）。系统中构件之间数据流的流动方式大大影响着系统的处理效率、误差传播以及设计简单化等方面。一个好的接口设计可以让构件集成变得更为容易并能辅助测试人员确认构件的功能。,1.3.3 建模原则,原则5：用户界面设计必须符合最终用户要求。在任何情况下，界面的设计都强调使用的方便性。用户接口是软件中可见的部分，无论系统的内部功能多么复杂，无论其数据结构多么容易理解，无论系统架构设计有多好，一个不好的界面设计都会令人感到整个软件很糟糕。原则6：构件级设计应是功能独立的。功能上独立是软件构件“单一思想”的度量方法。构件提供的功能应该是内聚的也就是说，它应该关注于一个且仅仅一个功能
35、或子功能。原则7：构件之间及构件与外部环境之间松散耦合。耦合可以通过很多方式来实现，如构件接口、消息传递及全局数据。耦合程度的提高，其错误传播的几率也会随之提高，整个软件的可维护性就会降低。因此，应该合理地保持较低的构件耦合度。,1.3.3 建模原则,原则8：设计表述（模型）应该尽可能地易于理解。设计的目的是向编码人员、测试人员以及未来的维护人员传递信息，如果设计过于复杂而难以理解，就无法成为一种高效的沟通媒介。原则9：设计应该迭代式进行。每一次迭代，设计者都应该力求简洁。就像大多数创造性活动一样，设计是迭代完成的，第一次迭代的工作是细化设计并纠正错误，之后的迭代就应该使设计变得尽量简单。,1
36、.3.3 建模原则,恰当地应用以上设计原则，软件工程师就能创造出兼顾内、外部高质量的设计。外部质量因素是软件在最终用户使用时所遇到的实际属性（例如速度、可靠性、正确性、可用性等），内部质量因素对与软件工程师来说非常重要，他们要从技术的角度做出高质量的设计。要想有一个高质量的内部设计，设计师们必须理解设计的基本概念。,1.3.3 建模原则,建模包括分析和设计，描绘了逐渐细化的软件。建模的目的是加深对所要完成工作的理解并为软件开发人员提供技术指导。建模原则就作为建立对软件进行表述的方法和注释的基础。构造包括了编码和测试循环，在这个循环中为每个构件生成源码并对其进行测试。,1.3.4 构造原则,构造
37、活动包括一系列编码和测试任务，从而为向客户和最终用户交付可运行软件做好准备。在现代软件工程中，编码可能是： 直接生成编程语言源代码（例如Java）； 使用待开发构件的类似设计的中间表示来自动生成源代码；或者 使用第四代编程语言（例如Visual C+）自动生成可执行代码。,1.3.4 构造原则,概念与编程风格、编程语言和编程方法紧密结合，相关的一些基本原则包括：（1）准备原则。在写下每行代码之前，要确保：理解所要解决的问题。理解基本的设计原则和概念。选择一种能够满足构建软件以及运行环境要求的编程语言。选择一种能提供工具以简化工作的编程环境。构件级编码完成后进行单元测试。,1.3.4 构造原则,
38、（2）编程原则。在开始编码时，要确保：遵循结构化编程方法来约束算法。考虑使用结对编程。选择能满足设计要求的数据结构。理解软件架构并开发出与其相符的接口。尽可能保持条件逻辑简单。开发的嵌套循环应使其易于测试。选择有意义的变量名并符合相关编码标准。编写注释，使代码具有自说明性。增强代码的可读性（例如：缩进和空行）。,1.3.4 构造原则,（3）确认原则。在完成第一阶段的编码之后要确保：适当进行代码走查。进行单元测试并改正所发现的错误。重构代码。（4）测试原则测试是一个以查找程序错误为目的的程序执行过程。一个好的测试用例能最大限度地找到尚未发现的错误。一个成功的测试能找到那些尚未发现的错误。,1.3
39、.4 构造原则,这些目标意味着软件开发者要设计一些能用最短的时间、最少的工作量来系统地揭示不同类型错误的测试。如果测试成功，就会发现软件中的错误。测试的第二个好处就是，它能表明软件功能的执行似乎是按照规格说明来进行的，行为需求和性能需求似乎也可以得到满足。此外，测试时收集的数据为软件的可靠性提供了一个很好的说明，并且从整体看来也为软件质量提供了一些说明。但是测试并不能说明某些错误和缺陷不存在；它只能显示出现存的错误和缺陷。在测试时保持这样一个观念是非常重要的。,1.3.5 部署原则,部署发生在向客户展示每个软件增量的时候，包括三个活动：交付、支持和反馈。交付的关键原则是管理客户期望并且能为客户
40、提供合适的软件支持信息；支持需要预先准备；反馈允许客户提出一些具有商业价值的变更意见，为开发者的下一个软件工程迭代周期提供输入。,1.3.5 部署原则,通常，由于现代软件过程模型实质上是演化式或是增量式的，因此，部署活动在软件开发完成之前要进行多次。每个交付周期都会向客户和最终用户提供一个可运行的并具有可用功能和特征的软件增量。每个支持周期都会为部署周期中所提到的所有功能和特征提供一些文档和人员帮助。每个反馈周期都会为软件开发团队提供一些重要的引导，以帮助修改软件功能、特征以及下一个增量所用到的方法。,1.3.5 部署原则,软件增量交付对于任何一个软件项目来说都是重要的里程碑。准备交付一个软件
41、增量时所应该遵从的重要原则包括：原则1：客户对软件的期望必须得到管理。客户通常并不希望看到软件开发团队对软件提交做出很多承诺后又很快令其失望，这将导致客户反馈变得没有积极意义，并且还会挫伤软件开发团队的士气。原则2：完整的交付包应该经过安装和测试。包含可执行软件的介质（包括Web下载）以及一些支持数据文件、文档和一些相关的信息都必须组装起来，并经过实际用户完整的测试。所有的安装脚本和其他一些可操作的功能都应该在所有可能的计算配置（例如：硬件、操作系统、外围设备、网络）环境中实施充分的检验。,1.3.5 部署原则,原则3：技术支持必须在软件交付之前就确定下来。最终用户希望在问题发生时能得到及时的
42、响应和准确的信息。如果技术支持跟不上或者根本就没有技术支持，那么客户会立即表示不满。支持应该是有计划的，准备好支持的材料并且建立适当的记录保持机制，这样软件开发团队就能按照支持请求种类进行分类评估。原则4：必须为最终用户提供适当的说明材料。软件开发团队交付的不仅仅是软件本身，也应该提供培训材料（如果需要的话）和故障解决方案，还应该发布关干“本次增量与以前版本有何不同”的描述。,1.3.5 部署原则,原则5：有缺陷的软件应该先改正再交付。迫于时间的压力，某些软件组织会交付一些低质量的增量，还在增量中向客户提出警告：“这些缺陷将在下次发布时解决。”这样做是错误的。在软件商务活动中有这样一条谚语：“
43、客户在几天后就会忘掉你所交付的高质量软件，但是他们永远忘不掉那些低质量的产品所出现的问题。软件会时刻提醒着问题的存在。”已交付的软件会为最终用户提供一些好处，同时它也会为软件开发团队提供一些有用的反馈。当一个增量投入使用后，应该鼓励最终用户对软件的功能、特性以及易用性、可靠性和其他特性做出评价。,1.4 什么是软件体系结构,事实上，从第一个程序被划分成模块开始，软件系统就有了体系结构。同时，程序员开始负责模块间的交互和模块装配的全局属性。尽管软件工程师通常也能够设计数据和体系结构，但在建造大型复杂系统的时候，往往是由专门人员，即数据库或者数据仓库的设计者来为系统创建数据体系结构，体系结构设计师
44、则根据软件需求分析中导出的需求选择合适的体系结构风格。,1.4 什么是软件体系结构,软件体系结构提供了待构造系统的整体视图，其设计主要是建立计算机系统所需的数据结构和程序构件，它需要考虑系统所采取的体系结构风格、系统组成构件的结构和性质，以及系统中所有体系结构构件之间的相互关系，数据设计是软件体系结构设计的一个组成部分。体系结构注重于早期的设计决策，始于数据设计，并提供了考虑多个可选系统结构优点的机制。,1.4.1 软件设计层次,系统设计是在多个层次上进行的，每一层要恰当地处理不同的设计关注点，所以精确地划分层次非常有用。在每个层次上都能找到：原始的和被组装的构件；非原始构件或系统的组装规则；
45、为系统提供语义的行为规则。不同层次各有不同，所以在每个层次上使用不同的符号、设计问题、分析技术。这样，每一层可以分别独立设计。层次之间是有关联的，每一层的元素都要与低一级层次的结构相对应，并通过低一级的层次来实现其功能。,1.4.1 软件设计层次,相对于计算机硬件系统的层次结构，同样，我们至少能够确定软件的三个设计层次：（1）体系结构级：这个级别的设计问题包括系统性能与构件之间的整体联系，构成元素是模块，模块通过各种方式互连；通过操作算子将子系统组装成一个系统。（2）代码级：这个级别的设计问题包括算法和数据结构，构成元素是编程语言原语，比如数值、字符、指针以及控制线程。基本的操作算子是算法和程
46、序设计语言提供的数据操作原语，组装机制包括记录、数组、过程。（3）执行级：这个级别的设计问题包括存储器的映射、数据格式配置、堆栈和寄存器的分配，构成元素是硬件所支持的位模式。使用机器代码来描述操作和组装。,1.4.2 体系结构,一个系统的体系结构是关于系统形式和结构的综合框架，包括系统构件和构件的整合。而软件体系结构必须对系统结构以及数据和过程构件相互协作的方式进行建模。,1.4.2 体系结构,举个例子：当人们在考虑建筑物的体系结构时，脑海中会出现很多不同的属性。在最简单的层面上，会考虑物理结构的整体形状。但在实际中，体系结构还包含更多的方面，它是各种不同建筑构件集成为一个有机整体的方式；是建
47、筑融入所在环境并与相邻的其他建筑相互吻合的方式；是建筑满足既定目标和满足业主要求的程度；是对结构的一种美学观感（建筑的视觉效果），以及纹理、颜色和材料结合在一起创建外观和内部“居住环境”的方式；是很多微小的细节灯具、地板类型、壁挂布置等的设计。,1.4.2 体系结构,但体系结构也可以是其他的东西，它是“数以千计的或大或小的决定”。其中一些决定是设计初期做出的，并可能会对所有的其他设计行为产生深刻影响。抽象地说，软件体系结构包括构成系统的设计元素的描述、交互、组合模式，以及在这些模式中的约束。一个具体的系统由构件的集合以及它们之间的关系组成，这样的系统又有可能成为一个更大的系统的组成元素。,1.
48、4.2 体系结构,人们已经普遍认识到：为系统设计一个合适的体系结构是系统取得长远的成功的关键因素，但是当前描述体系结构的实践一直是非形式化的。一般根据长期形成的非形式化的习惯方式来描述体系结构。通常，体系结构用方框连线图来抽象表示，并加以文字注释，来解释符号的含义，或者说明构件的选择以及它们之间交互的一些原理。,1.4.2 体系结构,例如，一些软件体系结构的典型描述如下：Camelot基于客户机-服务器模式，使用远程调用方法来实现应用程序和服务器之间的通信。抽象分层和系统分解为客户端提供了统一的系统接口，这样就使Helix能够适应客户端设备的多样性。这种体系结构推荐应用系统采用客户机-服务器模
49、式。我们已经选择了一种分布式的，面向对象的解决方案来管理信息资源。,1.4.2 体系结构,在长期的实践中，软件工程师已经有了一套共享的，语义丰富的词典，它由软件系统的习惯用语、模式、软件系统组织结构风格组成。比如说，识别一个管道-过滤器体系结构风格的实例：这个系统的主要功能是进行数据流的转换，并由各种独立实体的过滤器分别来实现，系统的响应时间和吞吐量能用以一种直接的方式计算出来。可见，尽管这种共享的词典很大程度上是非形式化，但是它能为软件工程师之间的交流提供语义丰富的内容。,1.4.2 体系结构,此外，与元素实际计算的细节相比，软件体系结构是非常抽象的，但这种结构为理解更大范围的、系统级的关注点，比如吞吐量、通信模式、执行控制结构、可伸缩性，以及系统演化的扩展方式等，提供了一个自然的框架。体系结构的描述就像是一个框架，系统属性在这个框架下进行扩充，并且，它在考察一个系统实现其整体需求的能力中扮演了非常重要角色。,
