软件体系结构-第4章(双语)

1、1软件体系结构Software Architecture 第四章 软件体系设计方法Chapter IV Software Architecture Design Method2本章要点 Key Points Architecture Design Summary Architecture Design Process Entire Architecture Programming Architecture Design Layer Pattern Layer Pattern Use principle Cases3体系结构设计的目标体系结构设计的目标 Architecture Design O

2、bject重用重用 Re-useble透明透明Transparent 扩展扩展Expanding 简明简明 Brief高效高效 Effective 安全安全 Safe4架构设计的复杂性架构设计的复杂性Architecture Design Complexity架构设计是一种权衡架构设计是一种权衡 Architecture is kind of balance 在设计的过程中总可以看到很多的矛盾体：在设计的过程中总可以看到很多的矛盾体： Contravention always reveals during architecture design 开放和整合开放和整合 (Opening and

3、Conformity)一致性和特殊化一致性和特殊化 (Coherence and Specialization)稳定性和延展性稳定性和延展性 (Stability and Tracbility) 5本章要点 Key Points Architecture Design Summary Architecture Design Process Entire Architecture Programming Architecture Design Layer Pattern Layer Pattern Use principle Cases6架构设计的过程模式架构设计的过程模式 Architectu

4、re Design Process Mode7体系结构和循环Architecture and Circle用例模型设计模型分布模型测试模型实现模型内容8体系结构设计各阶段Phase of Architecture 业务架构用例模型逻辑架构部署架构实现架构9各阶段设计的任务Task for Design Phasew业务分析阶段的任务： Task for Operation Analysis确定项目的业务目标和阐述实现该目标所必须满足的业务要求。 To define project operation object and illustrate operation requirement for

5、 objects satisfactionw技术要求阶段的任务 Task for Technical Requirement以业务分析阶段中形成的业务要求为起点，任务是将这些要求转化为可用来设计部署体系结构的技术规范。 Started from operation generated at operation analysis phase, to transfer them into technical criterion that used for architecture design and deploy.10各阶段设计的任务 Task for Design Phasew逻辑设计阶段 的

6、任务 Task for Logic Design 始于逻辑设计阶段。此阶段的任务是设计一个逻辑体系结构，它应该体现能够满足技术要求阶段所确定的使用用例和场景。 To design a logic architecture which express case and scene defined at technical requirement phasew部署设计阶段的任务 Task for Design deploy 任务是创建一个反映部署方案与物理环境的映射关系的部署体系结构。 To create deploy architecture which can reflect mapping

7、relation between design proposal and physical condition11各阶段设计的任务Task of Design Phasesw实现阶段 在测试环境中创建和部署试验性和/或原型部署设计和运行功能性测试来衡量与系统要求的符合度设计和运行负载测试来衡量峰值负载下的性能创建生产部署，可能需要分阶段部署到生产中12架构设计架构设计-架构源自需求架构源自需求Architecture Design-Architecture comes from Requirement 为什么要从需求开始？为什么要从需求开始？Why comes from requirement

8、?IT界的技术层出不穷，面对着如此之多的技术、平台、框架、函数库，我界的技术层出不穷，面对着如此之多的技术、平台、框架、函数库，我们如何选择一组适合软件的技术？们如何选择一组适合软件的技术？ New technology appears rapidly, facing so many technologyplatformframe and data base, how to select a suitable technology?每一个客户的软件都有自身的特点，如何才能够设计出符合客户利益的架每一个客户的软件都有自身的特点，如何才能够设计出符合客户利益的架构？构？ Each customer

9、 has its own character, how to design architecture which is suitable to customer interest?软件中往往都充斥着众多的问题，在一开始就把所有的问题都想清楚往往软件中往往都充斥着众多的问题，在一开始就把所有的问题都想清楚往往很难做到，但是如果不解决问题，风险又居高不下很难做到，但是如果不解决问题，风险又居高不下 Every software exist many issues and problem, it is not practical to solve them at beginning, but not

10、 reach to a solution will have very great risk.13架构设计架构设计-架构源自需求（举例）架构源自需求（举例）例例1：城市中自来水管的架设是一项非常的复杂的：城市中自来水管的架设是一项非常的复杂的工程。为了需要满足每家每户的需要，自来水管工程。为了需要满足每家每户的需要，自来水管组成了一个庞大的网络。在这样一个复杂的网络组成了一个庞大的网络。在这样一个复杂的网络中，如何完成铺设的任务呢。一般的做法是，先中，如何完成铺设的任务呢。一般的做法是，先找出问题的根源，也就是水的源头。从水源铺设找出问题的根源，也就是水的源头。从水源铺设一条管道通至城市，然后

11、根据城市的区域划分，一条管道通至城市，然后根据城市的区域划分，设计出主管道，剩下的就是使用的问题了，每家设计出主管道，剩下的就是使用的问题了，每家每户的管道最终都是连到主管道上的。因此，虽每户的管道最终都是连到主管道上的。因此，虽然自来水网络庞大复杂。但是真正的主管道的非然自来水网络庞大复杂。但是真正的主管道的非常简单的。常简单的。 14架构设计架构设计-架构源自需求（续）架构源自需求（续）需求的划分需求的划分Type of Requirement 功能需求：定义了软件能够做些什么？决定业务架构。功能需求：定义了软件能够做些什么？决定业务架构。 Functional requirement:

12、define what software can do and operation architecture 非功能需求：定义了一些性能、效率上的一些约束、规则，非功能需求：定义了一些性能、效率上的一些约束、规则，决定技术架构。决定技术架构。 Non functional requirement: define limitation and regulation for performance and efficiency, define technical architecture 变化案例：变化案例是对未来可能发生的变化的一个估计，变化案例：变化案例是对未来可能发生的变化的一个估计，决定架

13、构的范围。决定架构的范围。 Change case: subject to an evaluation to future potential change , define range of architecture 15架构设计架构设计-架构源自需求（举例）架构源自需求（举例）举例：举例：我们打算开发一个字处理软件，功能需求我们打算开发一个字处理软件，功能需求可以简单概括为格式化用户输入的文字，非功能可以简单概括为格式化用户输入的文字，非功能需求可能是格式化大小为需求可能是格式化大小为1000K的一段文字的处的一段文字的处理速度不能低于理速度不能低于10S，变化案例可能是推出多种，变化案例

14、可能是推出多种语言版本。那么我们在设计业务架构的时候，我语言版本。那么我们在设计业务架构的时候，我们会集中于如何表示文字、图象、媒体等要素，们会集中于如何表示文字、图象、媒体等要素，我们该需要有另外的技术架构来处理速度问题，我们该需要有另外的技术架构来处理速度问题，比如缓冲技术，对于变化案例，我们也要考虑相比如缓冲技术，对于变化案例，我们也要考虑相应的架构，比如把字体独立于程序包的设计。应的架构，比如把字体独立于程序包的设计。16本章要点 Key Points Architecture Design Summary Architecture Design Process Entire Arch

15、itecture Programming Architecture Design Layer Pattern Layer Pattern Use principle Cases17体系结构开发周期Architecture Development Period w标识构件 Identify componentw提出软件体系结构模型 Set up architecture modew把已标识的构件映射到软件体系结构中w Reflect identified components into architecture w分析构件之间的相互作用 Analysis interaction between

16、componentsw产生软件体系结构 Create architecture w软件体系结构正交化 Positive across of architecture 18标识构件Identify Componentw生成类图 Set up Genus Diagram w对类进行分组 Group genus w把类打包成构件 Pack genus into components19提出软件体系结构模型Set Up Architecture Modew在建立体系结构的初期，选择一个合适的体系结构风格是首要的。在这个风格基础上，开发人员通过体系结构模型，可以获得关于体系结构属性的理解。 At ear

17、ly phase of architecture, to select a suitable architecture style is key issues. Based upon this style, developer can gain understanding of architectures character through architectures mode.w此时，虽然这个模型是理想化的（其中的某些部分可能错误地表示了应用的特征），但是，该模型为将来的调整和演化过程建立了目标。 At this phase, even mode is still ideal, this m

18、ode build object for future adjustment and deduction.20把已标识的构件映射到软件体系结构中 Reflect identified components into architecture w把在第（1）阶段已标识的构件映射到体系结构中，将产生一个中间结构，这个中间结构只包含那些能明确适合体系结构模型的构件。wReflecting identified components into architecture will produce an intermediate architecture , this intermediate archi

19、tecture will just define suitable architecture component.21分析构件之间的相互作用 Analysis interaction between componentsw为了把所有已标识的构件集成到体系结构中，必须认真分析这些构件的相互作用和关系。可以使用UML的顺序图来完成这个任务。 To assembly all identified component into architecture must analysis interaction between components. Using UML s sequent diagram t

20、o complete this task22产生软件体系结构 Create architecture w一旦决定了关键的构件之间的关系和相互作用，就可以在第（3）阶段得到的中间结构的基础上进行精化。可以利用顺序图标识中间结构中的构件和剩下的构件之间的依赖关系，分析第（2）阶段模型的不一致性（例如丢失连接等） While interaction between components set up, perform extract action on the basis of intermediate architecture. Also can depending relationship to

21、 analysis phase II mode variance23软件体系结构正交化 Positive across of architecture w在（1）-（5）阶段产生的软件体系结构不一定满足正交性（例如：同一层次的构件之间可能存在相互调用）。整个正交化过程以原体系结构的线索和构件为单位，自顶向下、由左到右进行。通过对构件的新增、修改或删除，调整构件之间的相互作用，把那些不满足正交性的线索进行正交化。 Architecture generated from phase I to V may not fulfill to positive across. By adding , rev

22、ising and deleting of components, adjust interaction between components to correct all non positive across architecture.24演化开发阶段 Evolvement Development Phasew需求变动归类 Classify requirement adjustmentw制订体系结构演化计划 Plan architecture evolvement w修改、增加或删除构件 Reviseadd delete componentw更新构件的相互作用 Renew componen

23、ts interactionw产生演化后的体系结构 Produce evolved architecture w迭代 Repeatedly replacementw对以上步骤进行确认，进行阶段性技术评审w对所做的标记进行处理。 Identify all above steps, perform phases technical review, handle all marked components 25总体架构规划总体架构规划Collectively Architecture Layout 总体架构应该能够提供软件全局视图，包括所有的重要部分，定总体架构应该能够提供软件全局视图，包括所有的重

24、要部分，定义了各个部分的责任和之间的关系，而且还定义了软件设计需要义了各个部分的责任和之间的关系，而且还定义了软件设计需要满足的原则。满足的原则。 Collectively Architecture shall provide software general view, including all important component, define liability and relationship of every component and principle that software design requirement.总体架构的设计，应该是满足源自需求模式。总体架构的设计，

25、应该是满足源自需求模式。 Design Collectively Architecture shall meet requirement mode总体架构应该要能够满足架构的其它各种特点，例如简单、可扩总体架构应该要能够满足架构的其它各种特点，例如简单、可扩展性、抽象性展性、抽象性 Collectively Architecture shall meet all other components characters总体架构最大的用处就是保证设计的一致性和有效性Collectively Architectures most important usage is to assure consis

26、tency and validity 。 26总体架构规划的层次总体架构规划的层次-软件全局软件全局软件全局的架构设计是我们设计中所最关心的软件全局的架构设计是我们设计中所最关心的 。 Software general architecture is the most importance.为软件全局设置的架构愿景可以以原则、或是模式名的方式体现，并用自然语言或伪代码描述。需要强调的是总体架构规划的制定是根据不同的应用环境而变化的 Collectively architectures plan is adjusted upon conditions change27总体架构规划的层次总体架构规

27、划的层次-软件全局（续）软件全局（续）举例：在举例：在JAVA环境中环境中客户端采用前端浏览器界面。客户端采用前端浏览器界面。业务逻辑采用业务逻辑采用servlet，配合，配合JSP编写。编写。浏览器到服务器的数据采用集中处理，具体的方法浏览器到服务器的数据采用集中处理，具体的方法是在业务逻辑和前端浏览器之间采用是在业务逻辑和前端浏览器之间采用Front Control模式，接受前端浏览器传送过来的数据，并指派给模式，接受前端浏览器传送过来的数据，并指派给相应的业务逻辑处理。相应的业务逻辑处理。数据的合法性检验分为两个部分：数据的合法性检验分为两个部分：和业务逻辑无关的基本合法性验证在前端使用

28、和业务逻辑无关的基本合法性验证在前端使用Java Script处理。处理。和业务逻辑相关的合法性验证在业务逻辑层处理，可以使和业务逻辑相关的合法性验证在业务逻辑层处理，可以使用一个集中的用一个集中的servlet专门处理错误情况。专门处理错误情况。 28总体架构规划的层次总体架构规划的层次-子模块级、或是子问题级子模块级、或是子问题级Collectively architecture layer- sub-modesub-issues这里的架构规划制定本质上和全局的规划制定差不多，但是要注这里的架构规划制定本质上和全局的规划制定差不多，但是要注意一点，不能够和全局规划相违背。意一点，不能够和全

29、局规划相违背。 This establishment of this architecture shall not disobey to collectively architecture 在操作上，全局规划是设计团队共同制定出来的，而子模块级的在操作上，全局规划是设计团队共同制定出来的，而子模块级的架构规划就可以分给设计子团队来负责，而其审核则还是要设计架构规划就可以分给设计子团队来负责，而其审核则还是要设计团队的共同参与团队的共同参与 Collectively architecture is established by whole design team , while architec

30、ture for sub-mode may set up by responsible group . And review to architecture shall be performed by design team 好处：Advantage:确保各个子模块（子问题）间不至于相互冲突或出现空白地带To assure not to conflict or cause grey area between sub-mode 每个子设计团队可以从别人那里吸取设计经验 To gain design experience from other design group.29总体架构规划的层次总体架

31、构规划的层次-子模块级、或是子问题级（续）子模块级、或是子问题级（续） Collectively architecture layer- sub-modesub-issues子模块（子问题）间的耦合问题子模块（子问题）间的耦合问题 ： Coupling between sub-mode各个子模块间的耦合程度相对较小 子问题间的耦合程度就比较大 具体的做法：为子模块（子问题）制定出合同接口（Contact Interface） To set up contact interface for sub-mode 系统中的一些全局性的子问题最好是提到全局愿景中考虑 Collectively sub-i

32、ssue shall be considered into general view30总体架构规划的层次总体架构规划的层次-代码级的规划代码级的规划 Collectively architecture layer- Code Layout 严格的说这一层次的规划已经不是真正的愿景，而是具严格的说这一层次的规划已经不是真正的愿景，而是具体设计了体设计了 Instead of general view, it shall be considered as specific design这一个层次的规划一般可以使用类图、接口来表示。 This layout may express by diagr

33、am .interface 比较重要的工作在于问题如何分解和如何归并 The key point is how to break down and classify issues分解主要是从两个维度来考虑 Two Factors for break down :问题大小维 Issue s size 时间长短维 Time spending 31总体架构的形成过程总体架构的形成过程 总体架构规划的形成的源头是需求，需要特别指出的是，总体架构规划的形成的源头是需求，需要特别指出的是，这里的需求主要是那些针对系统基本面的需求。这里的需求主要是那些针对系统基本面的需求。 Source of collec

34、tively architecture is requirement which basic to also system .总体架构规划的主要目的就是为了能够在开发团队中传总体架构规划的主要目的就是为了能够在开发团队中传播设计思路，因此，总体架构规划包括基本的设计思路播设计思路，因此，总体架构规划包括基本的设计思路和基本的设计原则和基本的设计原则 Collectively architecture s object is to spread design thought within design team, so it including basic design thought and

35、principle.总体架构规划可能会有多种的视角 Collectively architecture may have many view points 32总体架构的形成过程总体架构的形成过程-使用架构模式使用架构模式 Total Architecture Process-Using Architecture Mode 33本章要点 Key Points Architecture Design Summary Architecture Design Process Entire Architecture Programming Architecture Design Layer Patte

36、rn Layer Pattern Use principle Cases34架构设计架构设计-分层模式分层模式Architecture- Layer Mode分而治之的思想是计算机领域非常重要的思想分而治之的思想是计算机领域非常重要的思想 Divide and Rule is very essential idea in computer field.分层的优势 ：Advantage of layer 上层的逻辑不需要了解所有的底层逻辑，它只需要了解和它邻接的那一层的细节 Upper layer not need to understand all other lower layer , on

37、ly need to understand layer connected .不同层间的耦合度明显降低。通过严格的区分层次，大大降低了层间的耦合度。 With layer division, coupling between layers is deducted. 某一层次的下级层可以有不同的实现 Certain layers lower layer can have different implement同一个层次可以支持不同的上级层 Same layer can support different upper layers35架构设计架构设计-分层模式（续）分层模式（续） Architec

38、ture- Layer Mode在企业应用中，有两个非常重要的概念：业务逻辑和持久性 In enterprise use, there are two key conceptions: operation logic and consistency 企业应用是围绕着业务逻辑进行开展的 Enterprise use is based upon operation logic 企业应用中大部分的数据都是需要可持久化的。因此，基础组织支持持久性就显得非常的重要 Most data from enterprise use is permanence, So basic organization sup

39、porting to permanence is very essential.36架构设计架构设计-分层模式（续）分层模式（续） Architecture- Layer Mode经典的三层理论将应用划分为三个层次：表示层（Presentation Layer领域逻辑层（Domain Logic Layer）数据层（Data source Layer37架构设计架构设计-分层模式举例分层模式举例 Architecture- Layer Mode38架构设计架构设计-分层模式举例（续）分层模式举例（续） Architecture- Layer Mode39架构设计架构设计-分层模式（续）分层模式

40、（续） Architecture- Layer Mode细分层次的主要考虑是设计的重用性。 Main consideration of layer subdivision is design importance 降低类层次的实现策略是分解行为、识别共同行为、抽取共性 Practical strategy of layer deduction is to behavior division/ common action identification/ common acquisition 具体做法：Way to act将操作层和知识层分离 Divide operation and knowle

41、dge layer利用继承 inheritance utilization分解并抽象对象的行为 Disassemble and abstract objects action40架构设计架构设计-分层模式（续）分层模式（续） Architecture- Layer ModeDivide operation and knowledge layer41架构设计架构设计-分层模式（续）分层模式（续） Architecture- Layer Modeinheritance utilization42本章要点 Key Points Architecture Design Summary Architec

42、ture Design Process Entire Architecture Programming Architecture Design Layer Pattern Layer Pattern Use principle Cases43如何使用分层技术？如何使用分层技术？How to use layer technology? 何时使用分层技术？一般来说，小型的软件使用分层并没有太大的意义，因为分层导致的成本超过它所能带来的好处 Generally speaking, layer technology is not benefit to minor software, it may ca

43、use additional development cost使用分层技术的依据是软件开发人员的实际需要 Layer technologys use is based upon software development s actual request.44如何使用分层技术？（续）如何使用分层技术？（续） How to use layer technology? 如何存放数据（状态）？如何存放数据（状态）？ How to store data ?数据（状态）的整个概念是多层体系的核心数据（状态）的整个概念是多层体系的核心 。由于状态的不同，类也表现出差异来 对于多层结构的软件，创建和销毁一个类

44、的开销是很大的，如果该软件支持分布式的话尤为如此 经典的设计-缓冲池 ( Damper)对象缓冲池的技术是用在中间的业务层上的 45处理好接口？处理好接口？Manage interface 一般层间的耦合度不宜过大，因此需要慎重的设计层之间的类调用方式 Be careful dispatch method between layers不同层之间仅仅知道目标层的接口，而不知道目标层的具体实现 different layer just know objective interface, but not know how to practice 在设计层间的接口时，除了考虑开发平台的约束之外，还有一

45、点是开发人员必须考虑的。那就是业务需要。 Consider both platform limitation and operation requirement46以迭代的方式进行分层以迭代的方式进行分层 Layer with repeatedly replacement每一次的迭代都能够对分层技术进行改进 Every repeatedly replacement may improve layer technology分层迭代不可以过于频繁，每一次的迭代都是对架构的重大修改 Not perform repeatedly replacement too much times, it will

46、cause huge change to architecture成功的迭代的效果是非常明显的，能够在接下来的开发周期中起到稳定架构，减少代码量，提升软件质量的功效 Good repeatedly replacement may stable architecture, decrease coding and improve software quality.迭代的推动力：源自于需求的演进以及现有架构的不稳定已经妨碍了软件进一步的开发 Impetus to repeatedly replacement is requirement s evolvement and unstable architecture that obstruct software development47层内的细分层内的细分 Subdivision of Layer分层的思路还可以适用于层的内部。层内的细分并没有固定的方式