-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathlocal-search.xml
78 lines (37 loc) · 33.8 KB
/
local-search.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
<?xml version="1.0" encoding="utf-8"?>
<search>
<entry>
<title>软件系统设计往年题</title>
<link href="/2024/06/22/%E8%BD%AF%E4%BB%B6%E7%B3%BB%E7%BB%9F%E8%AE%BE%E8%AE%A1%E5%BE%80%E5%B9%B4%E9%A2%98/"/>
<url>/2024/06/22/%E8%BD%AF%E4%BB%B6%E7%B3%BB%E7%BB%9F%E8%AE%BE%E8%AE%A1%E5%BE%80%E5%B9%B4%E9%A2%98/</url>
<content type="html"><![CDATA[<h2 id="设计模式题"><a href="#设计模式题" class="headerlink" title="设计模式题"></a>设计模式题</h2><ol><li>请至少说出三个面向对象的原则，并解释它们如何应用于策略模式？ Please name at least three <strong>Object-Oriented principles</strong>, and explain how they are applied in Strategy pattern?</li><li></li></ol><h2 id="简答题"><a href="#简答题" class="headerlink" title="简答题"></a>简答题</h2><ol><li>软件架构来自哪里？列举五种可能的软件架构的来源 Where do software <strong>architecture come from</strong>? List five possible sources of software architecture.</li><li>什么区分了软件产品线架构和单一产品的架构？What distinguishes an architecture for a software product line from architecture for a simple product?</li><li>【必考】如何进行质量属性方案建模？请使用”刺激-响应”图的格式进行建模 How to <strong>model quality attribute scenarios</strong>? Graphically model twoquality attributes in “stimulus-response” format:<ol><li>【2015】availiability and Performance</li><li>【2017】【2018】availiability and modifiability</li><li>【2019】interoperability and modifiability</li></ol></li><li>描述架构设计中架构模式和决策之间的关系。给出可以在架构设计过程中使用的任何四种决策的名称，并描述每种决策的目的。Describe the relationships between <strong>architectual patterns</strong> and <strong>tactics</strong> in architecture design. Give the name of any <strong>four tactics</strong> that can be used during architectural design and describe the purpose of each of them.</li><li>简要描述软件架构过程中的一般活动，以及每个活动的主要输入和输出。Briefly describe the general activities in a <strong>software architecture process</strong>, and the major inputs and outputs at each activity.</li><li>将以下每个问题（左侧）与解决该问题的架构风格/视图（右侧）对应起来。列出每个类别的样式的四个视图。Map each of the following questions (on the left) with the <strong>architectural style/view</strong> (on the right) that addresses the question. List four <strong>views</strong> of each category of <strong>style</strong>.</li><li>解释代理架构模式的上下文、好处和局限性。Explain the context, benefits and limitations of <strong>Broker Architecture Pattern</strong>.</li><li>为什么软件系统架构需要使用不同视图来文档化？给出4种示例视图的名称和目的。Why should a software architecture be <strong>documented</strong> using different <strong>differenet views</strong>? Give the name and purposes of 4 example views.</li><li>简要描述面向服务架构 (SOA) 的基本原则，并讨论 SOA 对互操作性、可伸缩性和安全性等质量属性的影响 Briefly describe the fundamental principles of <strong>Service Oriented Architecture(SOA)</strong> and discuss the <strong>impact of SOA</strong> on quality attributes like interoperability, scalability and security</li><li>描述架构权衡分析方法 (ATAM) 过程的每个阶段生成的输出。Describe the <strong>outputs</strong> generated from each phase of <strong>Architecture Tradeoff Analysis Method(ATAM)</strong> process.</li><li>在设计软件时应用了哪些通用设计策略？为每个策略提供一个带有软件架构的简明工作示例。What are <strong>general design strategies</strong> applied in designing software? Give a concise working example with software architecture for each strategy.</li><li>什么是ASR？列出提取和识别ASR的四种来源和方法。What are <strong>ASR</strong>? List four sources and methods for extracting and identifying ASRs.</li><li>典型的软件架构文档包中应该包含哪些内容？简要描述每个组件及其用途。What should be included in a typical <strong>software architecture documentation package</strong>? Briefly describe each component and its purpose.</li><li>描述 4+1 视图 Describe 4+1 <strong>view</strong>(掌握绘图)</li><li>软件设计的三个变化维度，每个维度的变化点。不同的绑定时间如何影响可修改性和可测试性。</li><li><strong>Layered pattern</strong> 和 <strong>Multi-tier pattern</strong> 的区别</li><li><strong>微服务</strong>和<strong>SOA</strong>的相同点、区别</li><li><strong>软件架构的关注点</strong>有哪些？<strong>利益相关方</strong>有哪些</li><li>Software requirements、Quality Attributes、ASRs之间的区别</li><li>Architecture、structure、design三者的关系</li><li>描述<strong>ADD</strong>的过程</li><li><strong>风险</strong>、<strong>敏感点</strong>、<strong>权衡</strong>分别是什么？</li><li>软件架构风格有哪些？</li></ol><h2 id="简答题解答"><a href="#简答题解答" class="headerlink" title="简答题解答"></a>简答题解答</h2><h3 id="1-10题"><a href="#1-10题" class="headerlink" title="1~10题"></a>1~10题</h3><p><strong>第一题</strong>：</p><ol><li>软件需求<ol><li>功能性需求</li><li>非功能性需求</li><li>约束</li></ol></li><li>ASRs</li><li>质量属性</li><li>涉众</li><li>技术环境</li><li>业务目标</li></ol><p><strong>第二题</strong></p><ol><li>产品线的目的：实现高可重用性、高修改性。</li><li>产品线之所以有效是因为通过重用可以充分利用产品的共性，从而产生声场的经济性。</li><li>在产品线架构中有一组明确允许发生的变化，然而对于常规架构来说，只要满足了单个系统的行为和质量目标，几乎任何实例都是可以的。因此，识别允许的变化是架构责任的一部分，同时还需要提供内建的机制来实现它们。</li></ol><p><strong>第三题</strong></p><p>如何进行质量属性方案建模</p><ol><li>刺激（Stimulus）：到达系统时需要考虑的条件。</li><li>刺激源（Source of Stimulus）：产生刺激的实体（人，系统或任何其他触发），可能是输入、信息等，对当前的状态的一个变化。</li><li>响应（Response）：刺激到来后工件开展的行为。</li><li>响应度量（Response Measure）：对刺激的响应以某种方法进行测量，以便可以测试需求（比如多长时间系统有反馈）</li><li>环境（Environment）：发生刺激时系统的状况，例如系统正常运行、系统过载、系统受到攻击、系统网络出现故障等。</li><li>工件（Artifact）：完成需求的整个系统或者系统的一部分（软件制品）。</li></ol><p><img src="https://p7g7gajvp5.feishu.cn/space/api/box/stream/download/asynccode/?code=ZDg3NTU1OWNkZDY5OGVlZjkyZDFlNDFlYzM0NWEwZDZfR3VCRk90elFPcWFtcEJFemlSeFdTNE1waEtjemZjcFdfVG9rZW46TUdVQmJKTk5abzlnVEZ4YkdzdWNVMzg3blZkXzE3MTkwNjMxMzc6MTcxOTA2NjczN19WNA" alt="质量属性建模方案"></p><p><strong>第四题</strong></p><ol><li>架构模式与决策之间的关系<ol><li>决策比架构模式更简单，仅有单一的结构或机制来应对单一的架构驱动</li><li>决策是构成架构模式的重要组成部分</li><li>架构模式通常将许多个决策组合在一起。</li><li>大多数架构模式都包含不同的决策，这些决策可能有共同的目的或者被用于实现不同的质量属性。</li><li>决策和架构模式共同构成了软件设计时的工具。</li></ol></li></ol><p><strong>第五题</strong></p><ol><li>创建商业案例 输入：问题域，输出：商业案例</li><li>了解用户需求 输入：用户模糊需求，输出：ASRs</li><li>选择体系结构，输入：备用体系结构，输出：被选中的体系结构</li><li>沟通体系结构 输入：被选中的体系结构 输出：架构设计文档</li><li>评估架构 输入：架构设计文档 输出：最终架构设计文档</li><li>实现体系结构 输入：最终架构设计文档 输出：架构具体实现</li><li>保证一致性 输入：架构具体实现 输出：保证一致性的架构具体实现</li></ol><p>其他：</p><p><img src="https://p7g7gajvp5.feishu.cn/space/api/box/stream/download/asynccode/?code=MjZlMTE4OTBlYjc2MzU5Nzk4NDg1OGY1Mjk1NTEwYjNfQXE0bUNhSTJTaHhQVzhhSlVsMkFLV0VtaVFkejZ6aDVfVG9rZW46VU1RRGJ1RXZob3ZTRFN4enJRTWNzek5FbllnXzE3MTkwNjMxMzc6MTcxOTA2NjczN19WNA" alt="体系结构设计过程"></p><ol><li>通过StackHolder获取到ASRs（架构攸关需求）</li><li>通过分析得到Prioritized Quality Attribute Scenarios(高优先级质量属性解决方案)和Requirements，Constraints(需求和约束)</li><li>将上述部分，结合模式和策略，综合可以得到架构的设计</li><li>根据架构的设计得到由模式决定的候选视图的示意图，之后完成文档化</li><li>选择、组合视图，将文档进行进一步的评估，这一部分需要StackHolder的参与、也需要Prioritized Quality Attribute Scenarios和文档等作为参考。</li></ol><p><strong>第六题</strong></p><p>连线and列出每个style的四个视图</p><ol><li>连线题<ol><li>它是如何构建为一组实现单元的？How it is structured as a set of implementation of units(Module Styles)</li><li>它是如何构建为一组具有运行时行为和交互的元素的？How it is structured as a set of elements that have runtime behavior and interactions?(Component-Connector Styles)</li><li>它与环境中的非软件结构有何关系？How does it relate to non-software structures in its environment?(Allocation Styles)</li></ol></li><li>Module Styles：分解视图、使用视图、泛化视图、分层视图、领域视图、数据模型视图</li><li>Component-Connector Styles：管道-过滤器视图、客户端-服务器视图、点对点视图、面向服务视图、发布-订阅视图</li><li>Allocation Styles：部署视图、安装视图、工作分配视图、其他分配视图。</li></ol><p><strong>第七题</strong></p><p>代理架构模式</p><ol><li>上下文：多个同步或异步交互的远程对象组成的系统，broker模式定义了运行时组件broker，它协调多个客户机和服务器之间的通讯。</li><li>好处：提高了Client和Server之间的交互性、提高可伸缩性和可扩展性、解决了单体应用的性能瓶颈、大规模集群的性能提高，但是单点性能会下降。</li><li>局限性：代理增加了前期复杂度、可能成为通信的屏障、可能成为攻击的目标、难以测试。</li><li>SOA延续了broker的思想，而SOA只在查找时通过register，分散了broker的职责，降低了单点风险。</li></ol><p><strong>第八题</strong></p><p>不同视图文档化</p><ol><li>原因<ol><li>不同视图支持不同的目标和用户，展现不同的元素和关系</li><li>不同视图的质量属性暴露程度不同</li></ol></li><li>4种视图(了解)：<ol><li>模块视图 Module View：提供一组连贯职责的实现单元</li><li>组件和连接器视图 C & C View：显示某些运行时存在的元素</li><li>分配视图 Allocation View：描述了软件元素与环境中的非软件元素之间的映射</li><li>质量视图 Quality Views，安全视图、性能视图、可靠性视图、沟通视图、异常（错误处理）视图</li><li>组合视图：将上述视图进行组合</li></ol></li></ol><p><strong>第九题</strong></p><ol><li>SOA的基本原则<ol><li>服务契约:服务按照描述文档所定义的服务契约行事</li><li>服务封装:除了服务契约所描述内容，服务将对外部隐藏实现逻辑</li><li>服务重用:将逻辑分布在不同的服务中，以提高服务的重用性</li><li>服务组合:一组服务可以协调工作，组合起来形成定制组合业务需求</li><li>服务自治:服务对所封装的逻辑具有控制权</li><li>服务无状态:服务将一个活动所需保存的资讯最小化</li></ol></li><li>SOA对互操作性的影响<ol><li>SOA具有更高的互操作性：符合开放标准，可以更好的重用服务</li><li>支持服务的自动识别、发现、注册和调用等等</li></ol></li><li>SOA对可伸缩性的影响<ol><li>SOA具有更高的可伸缩性：服务自身高内聚、服务间松耦合，最小化维护的影响</li><li>但是SOA也会带来系统复杂度较高的问题</li></ol></li><li>SOA对安全性的影响：<ol><li>中间件可能会成为性能的瓶颈</li><li>ESB等中间件都可以成为被攻击的目标</li><li>多服务导致攻击的跟踪、溯源和防御成为困难。</li></ol></li></ol><p><strong>第十题</strong></p><p>架构权衡分析方法每一阶段的输出</p><p>（实际上每一阶段做了什么、哪些参与者，最后都背掉）</p><p><strong>阶段0：准备和建立团队</strong></p><ol><li>参与者：评估团队领导和关键项目决策者</li><li>职责：架构设计文档=>评估计划</li><li>输入：架构设计文档</li><li>输出：评估计划</li></ol><p><strong>阶段一：评估（1）</strong></p><ol><li>参与者：评估团队和项目决策者</li><li>职责：<ol><li>介绍ATAM</li><li>介绍业务驱动因素</li><li>介绍架构</li><li>确定架构方法</li><li>生成质量属性效用树</li><li>分析架构方法</li></ol></li><li>输出：<ol><li>架构的简明介绍</li><li>业务目标的阐述</li><li>质量属性要求的优先级列表</li><li>效用树</li><li>风险点和无风险点</li><li>敏感点和权衡点</li></ol></li></ol><p><strong>阶段二：评估（2）</strong></p><ol><li>参与者：评估团队、项目决策者、涉众</li><li>职责：<ol><li>头脑风暴确定场景优先级</li><li>分析架构方法</li><li>展示评估结果给涉众</li></ol></li><li>输出：<ol><li>涉众们的优先级列表</li><li>风险主题和业务驱动因素受到的威胁</li></ol></li></ol><p><strong>阶段三：后续</strong></p><ol><li>参与者：评估团队、涉众</li><li>职责：最终评估，结果递交涉众审核，报告交给委托人</li><li>输出：最终评估报告</li></ol><h3 id="11-20题"><a href="#11-20题" class="headerlink" title="11~20题"></a>11~20题</h3><p><strong>第11题</strong></p><ol><li>抽象：忽略底层实现，专注高层的设计，比如将系统抽象为组件和连接件。</li><li>分解：将系统分解，比如将系统分解为各个模块。</li><li>分而治之：将每个模块分别处理</li><li>生成与测试：将一个特定的设计看作是一个假设；根据测试路径生成测试用例。</li><li>迭代与细化：使用迭代的方法，ADD方法多次迭代直到满足所有ASR</li><li>复用元素：重用在设计过程中可以复用的元素，重用现有架构</li></ol><p><strong>第12题</strong></p><ol><li>ASRs 架构攸关需求是对体系结构产生深远影响的需求</li><li>四种来源和方法：<ol><li>从需求文档中收集ASR：MoScoW方法和用户故事</li><li>采访涉众：质量属性工作坊(QAW)</li><li>通过了解业务目标来收集ASR：</li><li>通过质量属性效用树来管理ASR：通过方案量化描述需求后，逐渐对质量属性进行分解细化，直到包含量化指标为止。</li></ol></li></ol><p><strong>第13题</strong></p><p>软件架构文档包中的内容</p><ol><li>包含View和Beyond</li><li>Beyond部分：<ol><li>文档路线图：包含了范围和总结、简单摘要等。</li><li>视图的文档组织方式：描述了本文档中视图是如何组织的。</li><li>系统概述：从整体上描述了当前架构的简要说明、业务目标(驱动因素)等等。</li><li>视图之间的映射关系：描述了不同视图之间的映射关系。</li><li>系统原理：从整体上描述了当前架构的设计原理。</li><li>目录-索引、词汇表、首字母缩略词表。</li></ol></li><li>View部分<ol><li>styles and views(体系结构风格和视图)</li><li>Structural views<ol><li>module viwes</li><li>C & C views</li><li>Allocation views</li></ol></li><li>Quality Views</li></ol></li><li>每一个View的内容<ol><li>主要介绍：显示视图的元素和关系，以及图例</li><li>元素介绍，详细介绍第一部分中描述的元素、元素属性、关系属性和元素接口和行为。</li><li>上下文图：描述系统如何与环境相关</li><li>可变性指南：告知视图中可能出现的变化</li><li>基本原理：解释设计如何映射在视图中，以及其合理性。</li></ol></li></ol><p><strong>第14题</strong></p><p>4+1视图</p><ol><li>逻辑视图：描述了对架构而言重要的元素和他们之间的关系（功能需求）</li><li>过程视图：描述了元素之间的并发和交互。</li><li>物理视图：描述了主要过程和组件是如何被映射到硬件上的。</li><li>发展视图：描述了软件组件的内部组织联系（比如使用配置管理工具存储）。</li><li>用例场景（Use Case）：捕获架构需求，与一个或多个特定视图相关。</li></ol><p><img src="/../images/%E8%BD%AF%E4%BB%B6%E7%B3%BB%E7%BB%9F%E8%AE%BE%E8%AE%A1%E5%BE%80%E5%B9%B4%E9%A2%98/image-20240623221249262.png" alt="建模图"></p><p><strong>第15题</strong></p><ol><li>三个变化维度：<ol><li>面向对象 OOP，强调重用性、灵活性和扩展性。</li><li>面向方面 AOP，满足扩展的需求，可以在程序中自由的扩展功能</li><li>面向服务 SOA，是系统发布功能的一种方式，且基于这种方式不同的系统之间可以有效的沟通、协作。</li></ol></li><li>设计时，开发时，测试时，发布时，运行时：可修改性降低，可测试性升高</li></ol><p><strong>第16题</strong></p><p>分层模式和多层模式</p><ol><li>Layered Pattern是Module Style，而Multi-tier Pattern是Allocation Style</li><li>Layered Pattern是将任务拆解成一个个处于特定抽象级别的子层次，每层为下一层提供更高层次的服务，核心是关注点分离。</li><li>Multi-tier Patten中的层没有层次模式的强依赖关系，在不同部署环境中分层不同但是软件完成的内容一致。</li></ol><p><strong>第17题</strong></p><p>相同点：微服务和SOA都是分布式架构，微服务是SOA的一种扩展，都包含了服务契约、服务封装、服务重用、服务组合、服务自治和服务无状态等基本特点。</p><p>不同点：</p><p><img src="/../images/%E8%BD%AF%E4%BB%B6%E7%B3%BB%E7%BB%9F%E8%AE%BE%E8%AE%A1%E5%BE%80%E5%B9%B4%E9%A2%98/image-20240623221158086.png" alt="不同点"></p><p><strong>第18题</strong></p><ol><li>软件架构的关注点<ol><li>利益相关者 Stakeholders addressed</li><li>解决的问题，业务目标 Concerns addressed</li><li>语言，建模技巧 Language, modeling techniques</li><li>决策，模式 Tactics, Pattern</li></ol></li><li>利益相关方有哪些？<ol><li>顾客 Customer</li><li>用户 User</li><li>建筑师 Architect</li><li>需求工程师 Requirements engineer</li><li>设计师 Designer</li><li>实施者 Implementer</li><li>测试师，集成师 Tester, integrator</li><li>维护者 Maintainer</li><li>产品经理 Product manager</li><li>质量保证人 Quality assurance people</li></ol></li></ol><p><strong>第19题</strong></p><ol><li>软件需求包括功能性需求、非功能性需求（又称质量需求）、约束</li><li>质量属性是由业务目标决定的，是非功能性需求在系统上的反应</li><li>ASRs架构攸关需求是对于体系结构有着深远影响的需求，是软件需求的一部分。</li></ol><p><strong>第20题</strong></p><p>design包含体系结构，体系结构包含结构</p><ol><li>体系结构是设计的一部分，体系结构都是设计，设计不一定是体系结构</li><li>结构是静态、逻辑的，是关于系统如何组成的；体系结构包含结构，还有组件之间的联系等动态行为</li></ol><h3 id="21-23题"><a href="#21-23题" class="headerlink" title="21~23题"></a>21~23题</h3><p><strong>第21题</strong></p><p>ADD的步骤</p><ol><li>确定有足够的需求信息</li><li>选择要分解的系统元素</li><li>确定所选元素的ASR</li><li>选择符合ASR的设计<ol><li>找出设计问题</li><li>列出子关注点替代模式/决策</li><li>从清单中选择模式/决策</li><li>确定模式/决策与ASR之间的关系</li><li>记录初步的架构视图</li><li>评估并解决不一致的问题</li></ol></li><li>实例化架构元素并分配职责</li><li>实例化元素定义接口</li><li>验证和完善需求</li><li>重复进行2-7步直到满足所有的ASR</li></ol><p><strong>第22题</strong></p><p>风险：可能对质量属性产生负面影响的架构决策（比如分层模式可能造成额外的性能损耗）</p><p>权衡<strong>：</strong> 影响多个质量属性的架构决策（比如分层消耗性能，但增强系统的可修改性）</p><p>敏感点：特定质量属性敏感的架构决策。（比如性能敏感的系统，决定使用缓存中间件）</p><p><strong>第23题</strong></p><ol><li>module Styles：认为体系结构是由模块组成。模块是实现单元的集合，它提供了一组一致的职责。</li><li>C & C Styles 认为体系结构是由组件(主要的处理单元和数据存储)、连接件(组件之间的交互路径)组成的。</li><li>Allocation Styles 认为体系结构是由软件元素(软件元素具有环境所需的属性)和环境元素(环境元素有提供给软件的属性)组成的，展示了软件如何与环境关联。</li></ol>]]></content>
<categories>
<category>考试复习</category>
<category>软件系统设计</category>
</categories>
<tags>
<tag>软件系统设计</tag>
<tag>架构设计</tag>
</tags>
</entry>
<entry>
<title>软件系统设计-架构设计背诵</title>
<link href="/2024/06/22/%E8%BD%AF%E4%BB%B6%E7%B3%BB%E7%BB%9F%E8%AE%BE%E8%AE%A1-%E6%9E%B6%E6%9E%84%E8%AE%BE%E8%AE%A1%E8%83%8C%E8%AF%B5/"/>
<url>/2024/06/22/%E8%BD%AF%E4%BB%B6%E7%B3%BB%E7%BB%9F%E8%AE%BE%E8%AE%A1-%E6%9E%B6%E6%9E%84%E8%AE%BE%E8%AE%A1%E8%83%8C%E8%AF%B5/</url>
<content type="html"><![CDATA[<h2 id="1、ADD（属性驱动设计）"><a href="#1、ADD（属性驱动设计）" class="headerlink" title="1、ADD（属性驱动设计）"></a>1、ADD（属性驱动设计）</h2><h3 id="ADD的步骤"><a href="#ADD的步骤" class="headerlink" title="ADD的步骤"></a>ADD的步骤</h3><ol><li>确定有足够的需求信息</li><li>选择要分解的系统元素</li><li>确定元素的ASR</li><li>选择符合ASR的设计</li><li>实例化架构元素并分配职责</li><li>实例化元素接口</li><li>验证完善需求</li><li>重复2-7，知道满足所有ASR</li></ol><h3 id="ADD输出"><a href="#ADD输出" class="headerlink" title="ADD输出"></a>ADD输出</h3><ol><li>软件元素：履行各种角色和职责的开发工件</li><li>角色：一组相关职责</li><li>责任：软件元素的功能、数据</li><li>属性：软件元素的附加信息</li><li>关系：软件元素的交互、关联定义</li></ol><h2 id="2、ATAM（架构权衡分析方法）"><a href="#2、ATAM（架构权衡分析方法）" class="headerlink" title="2、ATAM（架构权衡分析方法）"></a>2、ATAM（架构权衡分析方法）</h2><p>Architectural Tradeoff Analysis Method：架构权衡分析方法</p><p>四阶段</p><p><strong>阶段0：准备和建立团队</strong></p><ol><li>参与者：评估团队领导和关键项目决策者</li><li>职责：架构设计文档=>评估计划</li><li>输入：架构设计文档</li><li>输出：评估计划</li></ol><p><strong>阶段一：评估（1）</strong></p><ol><li>参与者：评估团队和项目决策者</li><li>职责：<ol><li>介绍ATAM</li><li>介绍业务驱动因素</li><li>介绍架构</li><li>确定架构方法</li><li>生成质量属性效用树</li><li>分析架构方法</li></ol></li><li>输出：<ol><li>架构的简明介绍</li><li>业务目标的阐述</li><li>质量属性要求的优先级列表</li><li>效用树</li><li>风险点和无风险点</li><li>敏感点和权衡点</li></ol></li></ol><p><strong>阶段二：评估（2）</strong></p><ol><li>参与者：评估团队、项目决策者、涉众</li><li>职责：<ol><li>头脑风暴确定场景优先级</li><li>分析架构方法</li><li>展示评估结果给涉众</li></ol></li><li>输出：<ol><li>涉众们的优先级列表</li><li>风险主题和业务驱动因素受到的威胁</li></ol></li></ol><p><strong>阶段三：后续</strong></p><ol><li>参与者：评估团队、涉众</li><li>职责：最终评估，结果递交涉众审核，报告交给委托人</li><li>输出：最终评估报告</li></ol><h2 id="3、软件设计策略or架构设计策略"><a href="#3、软件设计策略or架构设计策略" class="headerlink" title="3、软件设计策略or架构设计策略"></a>3、软件设计策略or架构设计策略</h2><ol><li>抽象：忽略底层实现，专注高层的设计</li><li>分解：将系统分解，比如将系统分解为各个模块</li><li>分而治之：每个模块分别处理</li><li>生成与测试</li><li>迭代与优化：迭代，ADD反复迭代直到满足所有ASR</li><li>复用元素</li></ol><h2 id="4、软件架构过程"><a href="#4、软件架构过程" class="headerlink" title="4、软件架构过程"></a>4、软件架构过程</h2><ol><li>创建商业案例 输入：问题域，输出：商业案例</li><li>了解用户需求 输入：用户模糊需求，输出：ASRs</li><li>选择体系结构，输入：备用体系结构，输出：被选中的体系结构</li><li>沟通体系结构 输入：被选中的体系结构 输出：架构设计文档</li><li>评估架构 输入：架构设计文档 输出：最终架构设计文档</li><li>实现体系结构 输入：最终架构设计文档 输出：架构具体实现</li><li>保证一致性 输入：架构具体实现 输出：保证一致性的架构具体实现</li></ol><h2 id="5、质量属性方案建模"><a href="#5、质量属性方案建模" class="headerlink" title="5、质量属性方案建模"></a>5、质量属性方案建模</h2><ol><li>刺激源：产生刺激的实体</li><li>刺激：到达系统需要考虑的条件</li><li>工件：系统的一部分</li><li>环境：此时系统的状况</li><li>响应：应对刺激的反应</li><li>响应度量：以某种方式测试响应，以便测试需求是否达到</li></ol><h2 id="6、风险、权衡、敏感点"><a href="#6、风险、权衡、敏感点" class="headerlink" title="6、风险、权衡、敏感点"></a>6、风险、权衡、敏感点</h2><p><strong>风险</strong>：可能对质量属性产生负面影响的架构决策（比如分层模式可能造成额外的性能损耗）</p><p><strong>权衡：</strong> 影响多个质量属性的架构决策（比如分层消耗性能，但增强系统的可修改性）</p><p><strong>敏感点</strong>：特定质量属性敏感的架构决策。（比如性能敏感的系统，决定使用缓存中间件）</p><h2 id="7、文档不同视角"><a href="#7、文档不同视角" class="headerlink" title="7、文档不同视角"></a>7、文档不同视角</h2><p>不同视图支持不同用户与目标，展现不同元素和关系；不同视图的质量属性暴露程度不同</p><ol><li>逻辑视图：描述了在体系结构上明显重要的元素以及他们之间的关系 Logical view</li><li>过程视图：描述了体系结构中的并发和交流元素 Process view</li><li>物理视图：描述了主要过程和部件是如何映射到应用硬件上的 Physical view</li><li>开发视图：描述了软件部件是如何在软件内部组织的，比如配置管理工具 Development view</li><li>体系结构用例：描述如何实现特定的功能需求 Architecture use cases</li></ol><h2 id="8、软件需求、质量属性、架构攸关需求"><a href="#8、软件需求、质量属性、架构攸关需求" class="headerlink" title="8、软件需求、质量属性、架构攸关需求"></a>8、软件需求、质量属性、架构攸关需求</h2><ol><li><strong>软件需求</strong>：包括功能性需求，非功能性需求和约束<ol><li>功能性需求：功能性需求定义了系统必须做什么并且强调了系统如何提供价值给涉众</li><li>非功能性需求：非功能性需求和体系结构需求是质量需求的替代术语，在任何设计决策中都必须考虑非功能性需求。分为external（比如性能，可用性，易用性），internal（比如可维护性、可移植性等）</li><li>约束：约束是具有零自由度的设计决策</li></ol></li><li>质量属性：质量属性是由业务目标决定的，是非功能性需求在系统上的反应</li><li>架构攸关需求：架构攸关需求是对体系结构有着深远影响的需求，是软件需求的一部分</li></ol><h2 id="9、ASR的来源"><a href="#9、ASR的来源" class="headerlink" title="9、ASR的来源"></a>9、ASR的来源</h2><ol><li>需求文档</li><li>涉众采访</li><li>业务目标</li><li>质量属性实体书树管理：对质量属性细化，直到包含量化指标</li></ol><h2 id="10、architecture、structure、design"><a href="#10、architecture、structure、design" class="headerlink" title="10、architecture、structure、design"></a>10、architecture、structure、design</h2><p>design包含体系结构，体系结构包含结构</p><ol><li>体系结构是设计的一部分，体系结构都是设计，设计不一定是体系结构</li><li>结构是静态、逻辑的，是关于系统如何组成的；体系结构包含结构，还有组件之间的联系等动态行为</li></ol><h2 id="11、微服务"><a href="#11、微服务" class="headerlink" title="11、微服务"></a>11、微服务</h2><p>微服务架构是把应用程序功能性分解为一组服务的架构风格，每一个服务都是由一组专注、内聚的功能职责组成。</p><h3 id="特点"><a href="#特点" class="headerlink" title="特点"></a>特点</h3><ol><li>通过服务组件化</li><li>内聚和解耦：每一个服务自身高度内聚，服务与服务之间解耦</li><li>围绕业务能力组织</li><li>去中心化</li><li>基础设施自动化</li><li>服务与演进</li></ol><h3 id="挑战"><a href="#挑战" class="headerlink" title="挑战"></a>挑战</h3><ol><li>微服务的拆分和定义，如何拆、结果优劣</li><li>进程间通信机制复杂性高于方法调用、局部故障</li><li>部署复杂性：技术易购、相互隔离、经济高效</li><li>运维复杂性：自动化部署工具、Docker容器编排工具</li></ol><h3 id="SOA-vs-MSA"><a href="#SOA-vs-MSA" class="headerlink" title="SOA vs MSA"></a>SOA vs MSA</h3><p>面向服务体系结构 vs 微服务架构</p><table><thead><tr><th></th><th>SOA</th><th>MSA</th></tr></thead><tbody><tr><td>服务间通信</td><td>1.智能管道，如ESB<br>2.重量级协议，如SOAP</td><td>1. 哑管道，如消息代理，或服务之间点对点通信<br>2.轻量级协议，如REST</td></tr><tr><td>数据管理</td><td>全局数据模型并共享数据库</td><td>每个服务有自己的数据模型和数据库</td></tr><tr><td>典型服务规模</td><td>较大的单体应用</td><td>较小的服务</td></tr></tbody></table>]]></content>
<categories>
<category>考试复习</category>
<category>软件系统设计</category>
</categories>
<tags>
<tag>软件系统设计</tag>
<tag>架构设计</tag>
</tags>
</entry>
<entry>
<title>Hello World</title>
<link href="/2024/06/21/hello-world/"/>
<url>/2024/06/21/hello-world/</url>
<content type="html"><![CDATA[<p>Welcome to <a href="https://hexo.io/">Hexo</a>! This is your very first post. Check <a href="https://hexo.io/docs/">documentation</a> for more info. If you get any problems when using Hexo, you can find the answer in <a href="https://hexo.io/docs/troubleshooting.html">troubleshooting</a> or you can ask me on <a href="https://github.com/hexojs/hexo/issues">GitHub</a>.</p><h2 id="Quick-Start"><a href="#Quick-Start" class="headerlink" title="Quick Start"></a>Quick Start</h2><h3 id="Create-a-new-post"><a href="#Create-a-new-post" class="headerlink" title="Create a new post"></a>Create a new post</h3><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">$ hexo new <span class="string">"My New Post"</span></span><br></pre></td></tr></table></figure><p>More info: <a href="https://hexo.io/docs/writing.html">Writing</a></p><h3 id="Run-server"><a href="#Run-server" class="headerlink" title="Run server"></a>Run server</h3><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">$ hexo server</span><br></pre></td></tr></table></figure><p>More info: <a href="https://hexo.io/docs/server.html">Server</a></p><h3 id="Generate-static-files"><a href="#Generate-static-files" class="headerlink" title="Generate static files"></a>Generate static files</h3><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">$ hexo generate</span><br></pre></td></tr></table></figure><p>More info: <a href="https://hexo.io/docs/generating.html">Generating</a></p><h3 id="Deploy-to-remote-sites"><a href="#Deploy-to-remote-sites" class="headerlink" title="Deploy to remote sites"></a>Deploy to remote sites</h3><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">$ hexo deploy</span><br></pre></td></tr></table></figure><p>More info: <a href="https://hexo.io/docs/one-command-deployment.html">Deployment</a></p>]]></content>
</entry>
</search>