软件架构设计 |
您所在的位置：网站首页 › 架构architecture › 软件架构设计 |
软件架构设计
|
Software Architecture
软件架构是结构和系统结构，包含了软件元素、这些组件的外部可视化属性以及他们之间的关系。Software Architecture is the structure or structures of the system, which comprise software elements, the externally visible properties of these components, and the relationship among them.（In practice 书中的定义） 单独的盒式模型不是架构，但是是一个开始的点 Box-and-line drawings alone are not architecture, but a starting point. 架构包含了组件的行为 Architecture includes behaviour of components. Role of Architecture 架构是代表决定如何实现需求的决策的第一批人工制品。作为早期设计决策的体现，架构代表了那些最难更改的设计决策，因此值得最仔细的考虑 An architecture is one of the first artefacts that represents decision on how requirements are to be achieved. As the manifestation of early design decisions, the architecture represents those design decisions that are hardest to change and hence deserve the most careful consideration. 架构是成功完成产品线工程，与独立开发每个系统相比，以较少的工作量，成本和风险来有序地开发一系列相似系统的关键要素 An architecture is the key artefact in achieving successful product line engineering, the disciplined development of a family of similar system with less effort, expense, and risk than developing each system independently. 当有人开始在系统上工作时，架构通常是首先要检查的设计工件 An architecture is usually the first design artefact to be examined when someone starts working on a system. 软件架构为维护和修改决策提供了参考框架 Software architecture provides a framework of reference for maintenance and modification decisions. Why is software architecture important? 软件架构提供了沟通的工具 Software architecture provides a vehicle for communication 软件架构是一个可以确定和谈判利益冲突的参考框架 It is a frame of reference in which competing interests may be identified and negotiated 和用户讨论需求 Negotiating requirements with users 保证客户获取到过程和成本等信息 Keeping customer informed of progress, cost etc. 实现决策和分配的管理 Implementing management decisions and allocations. 软件架构表现了最早期的决策集合 Software architecture manifests the earliest set of design decisions 约束着实现和开发者 It constraints the implementation and developers 实现必须要符合架构 Implementation must conform to architecture 资源分配的决策约束着单独模块的实现 Resource allocation decisions constrain implementations of individual components 表现了早期的设计决策 Manifestation of early design decisions 软件架构体现为了开发和维护工作的组织结构 Software architecture dictates organizational structure for development & maintenance efforts, e.g. 划分为团队 Division into teams 预算，计划单位 Units for budgeting, planning 基础的工作拆分架构 Basis of Work Breakdown Structure 文档的组织 Organization for documentation CM 库的组织 Organization for CM libraries 集成的基础 Basis of integration 测试计划、测试的基础 Basis of test plans, testing 运维的基础 Basis of maintenance 架构促进/阻碍质量属性的实现，比如灵活性、安全性、易用性 Architecture facilitates/ hinders achievement of quality attributes, e.g. modifiability, security, usability etc. 架构会影响质量，但由于涉及许多其他因素，因此可能无法保证质量。Architecture influences qualities, but may not guarantee them as there are a number of other factors involved. 架构引发有关潜在变更的讨论（系统的 80%的工作是部署后的工作） An architecture invokes discussion about potential change (80% of effort for a system is post-deployment effort) 架构将更改分为三种类型 Architecture categorise changes into three types: 本地：信号组件修改 Local: signal component modification 非本地：几个组件修改。Non-local: several component modification. 架构：修改系统的基本结构，通信和协调机制 Architectural: modification of the system's basic structure, communication, and coordination mechanism 架构是一种可迁移和可重用的抽象：一对多映射（一种架构，许多系统）Architecture is a transferable and reusable abstraction one-to-many mapping (one architecture, many systems) 架构是产品通用性的基础。整个产品线共享一个架构 Architecture is the basis for product commonality. A whole product line shares a single architecture. 可以通过体系结构集成独立开发的组件来开发系统（CBSE）Systems can be developed by integrating independently developed components via architecture (Component-Based Software Engineering - CBSE) Software Architecture Process
需求中往往存在有开发人员和用户的矛盾，我们需要将这一个部分进行转化。 Functional Requirements 功能性需求定义了系统必须做什么并且强调了系统如何提供价值给涉众 Functional requirements state what the system must do and address how the system provides value to the stakeholders. 功能性需求意味着系统的行为 Functional requirements means the behaviour of the system. 功能是系统完成其预期工作的能力，例如，使学生能够在线注册。Functionality is the ability of the system to do the work for which it was intended, e.g., enable students to enroll online. 通过使用许多可能的结构可以实现功能。Functionality may be achieved through the use of any number of possible structures. 功能在很大程度上与结构无关，因为它可以作为单个整体系统存在而没有任何内部结构。Functionality is largely independent of structure, because it could exist as a single monolithic system without any internal structure. Quality Requirements 质量需求是系统应在其功能要求之上提供的整个系统的合乎需要的特性（又称质量属性） Quality requirements are desirable characteristics of the overall system (aka. quality attributes) that system should provide on the top of its functional requirements. 质量要求是功能要求或整个产品的资格。软件体系结构限制了分配 Quality requirements are qualifications of the functional requirements or of the overall product. 如果质量属性很重要，则将功能（映射）到各种结构上。Software architecture constrains the allocation(mapping) of the functionality onto various structures if quality attributes are important. Non-functional Requirements 非功能要求或体系结构要求是用于质量属性的替代术语 Non-functional requirements or architectural requirements are alternative terms used for quality attributes. 不可能获得正确的功能然后尝试适应非功能性需求（没有改装质量）It is not possible to get the functionality right and then try to accommodate non-functional requirements (NO retro-fitting quality). 在任何设计决策中都必须考虑非功能性要求 Non-functional requirements must be taken into account during any design decision. 非功能性需求分为两大类 There are two broad categories of non-functional requirements: 在执行过程中可观察（外部）：系统满足其行为要求的程度如何？例如性能，安全性，可用性，易用性等。Observable (External) during execution: How well a system satisfies its behavioural requirements? e.g., performance, security, availability, usability etc. 执行期间不可观察（内部）：系统的维护，集成或测试有多容易？ 例如，可修改性，可移植性，可重用性，可测试性等。Not observable (Internal) during execution: How easily a system can be maintained, integrated, or tested? e.g., modifiability, portability, reusability, testability etc. 约束了限定的边界，之后的架构是在这个边界内找到最优的解。 Quality Attributes 开发完成后，质量属性不能添加到软件密集型系统中 Quality isn't something that can be added to a software intensive system after development finishes. 在软件开发的所有阶段都需要解决质量问题 Quality concerns need to be addressed during ALL phases of the software development. 业务目标决定了系统必须具备的质量。Business goals determine qualities that a system must posses. 质量属性高于系统功能，是系统功能、服务和行为的基本陈述 Quality attributes are over and above of system's functionality, which is the basic statement of the system's capabilities, services, and behaviours. 功能通常在开发计划中占据重要位置 Functionality usually takes the front seat in the development plan. 但是，系统通常因为它们缺乏所需的质量级别，即难以维护，移植或扩展而被重新设计 However, systems are usually redesigned because they lack desired level of quality, i.e. difficult to maintain, port, or scale. 软件体系结构限制了各种质量属性的实现，例如性能，安全性，可用性等 Software architecture constrains the achievement of various quality attributes, e.g., performance, security, usability etc. 这就是为什么软件体系结构被认为是解决质量问题的最合适的层次 That is why software architecture is considered the most appropriate level of addressing the quality Issues. 质量属性不完全取决于设计，也不取决于实现或部署 No quality attribute is entirely dependent on design, nor is it dependent on implementation or deployment. Specifying Quality Attributes 要在架构级别对其进行评估，必须对质量属性进行精确定义。Precise definition of a quality attribute is necessary to evaluate it at the architecture level. 质量属性方案用于定义所需的质量属性。Quality attribute scenarios are used to define the desired quality attribute. 方案是具有一定结构的简单句子。场景的两个主要类别是 Scenarios are simple descriptions with certain structure. Two main classes of scenarios are: 通用方案是与系统无关的方案，用于指导质量属性要求的规范 General scenarios are system independent scenarios to guide the specification of quality attribute requirements. 具体方案是系统特定方案，用于指导特定系统的质量属性要求的规范。它们是一般方案的实例 Concrete scenarios are system specitic scenarios to guide the specification of quality attribute requirements for a particular system. They are instances of general scenarios. 这个方案就是 4+1 视图中的 1（Use Case） General Scenarios 通用方案提供了一个框架，用于生成大量通用的，独立于系统的，质量属性特定的方案。General scenarios provide a framework for generating a large number of generic, system-independent, quality attribute specific scenarios. 每种情况都可能但不一定与我们所关注的系统相关。Each scenario is potentialy but not necessarily relevant to the system We are concerned with. 为了使一般情况对特定系统有用，我们必须使它们特定于系统。To make the general scenario useful for a particular system, we must make them system specific. 使通用场景系统特定于特定环境意味着将其转换为特定系统的具体术语。Making a general scenario system specific means translating it into concrete terms for the particular system. Modeling Quality Attribute Scenarios 重要
只要定义好这 6 个元素，就能锁定架构的一个场景，之后可以用来进行架构的设计。 刺激和响应发生在一个环境中：系统正常运行、系统过载、系统受到攻击、系统网络等出现了故障。 Tactics 策略（原子级别的最小的决定） 风格或样式运用策略来提供预期的收益 Style or pattern applies tactics to provide the promised benefit. 策略是影响质量属性响应控制的设计决策，例如冗余。A tactic is a design decision, .e.g. redundancy, that influences the control of a quality attribute response. 策略的集合称为体系结构策略。A collection of tactics is called an architectural strategy. 系统设计包括一组设计决策，其中一些决策可帮助控制质量属性响应；其他确保系统功能的实现 A system design consists of a collection of design decisions: some of these decisions help control the quality attribute response; others ensure achievement of system functionality. 像模式一样，策略也可以由其他策略组成，例如，冗余可以由数据的冗余，计算的冗余组成。设计人员根据需求选择一个或另一个 Like patterns, tactics may also be composed of other tactics, e.g., redundancy may be composed of redundancy of data, redundancy of computation——Designer chooses one or other depending upon requirements. 策略可以用作策略等级 Tactics can be used as hierarchy of tactics.
架构是设计决策的集合。Architecture is a collection of design decisions. 七类设计决策（可能重叠） Seven categories of design decisions (may overlap): 职责分配 Allocation of responsibilities：将大的职责进行分配 协调模型 Coordination model：各部分之间的沟通、交互 数据模型 Data model：数据格式、存储方式（缓存等） 资源管理 Management of resources：CPU、网络、内存、时间（部分时间敏感的场景）等资源 架构元素之间的映射 Mapping among architecture elements：将架构元素如何映射到软件的实现上 绑定时间决策 Binding time decisions： 系统的变化可以在什么时间点前需要固定下来，也就是这个时间前，系统还是可以变化的，但是这个时间之后就不可以变化了 比如选择安装环境是需要在一个时间点前完成的，技术是否添加、编译时间、初始化时间，运行时绑定，但运行时是弹性最大的 实际上我们希望绑定时间越往后越好，但是也就要付出相应的代价。 技术选择 Choice of technology：前面的部分都确定后，我们可以选择技术栈相对比较局限，解空间已经被压缩了。 Attributes Adaptability 适应性 Extensibility 可扩展性 Availability 可用性 Modularity 模块化 Configurability 可配置性 Portability 便携性 Flexibility 灵活性 Reusability 可重用性 Interoperability 互操作性 Testability 可测试性 Performance 性能 Auditability 可审核性 Reliability 可靠性 Maintainability 可维护性 Responsiveness 响应能力 Manageability 可管理性 Recoverability 可恢复性 Sustainability 可持续性 Scalability 可扩展性 Supportability 可支持性 Stability 稳定性 Usability 易用性 Security 安全性 Constraints 约束是具有零自由度的设计决策。A constraint is a design decision with ZERO degrees of freedom. 约束是已经做出的预先指定的设计决策。Constraints are pre-specified design decisions that have been already made. 通过接受设计决策并将其与其他受影响的设计决策进行协调，可以满足约束条件。Constraints are satisfied by accepting the design decision and reconciling it with other affected design decisions. Quality Attributes & Tactics Availability可用性是大多数 IT 应用程序的关键要求 Key requirement for most IT applications 度量方式：以所需的可用时间比例来衡量，例如 Measured by the proportion of the required time it is useable, e.g. 营业时间内 100% 可用 100% available during business hours 每周计划的停机时间不超过 2 个小时 No more than 2 hours scheduled downtime per week - 24x7x52 (100% availability)相关性：与应用程序的可靠性有关 Related to an application's reliability 不可靠的应用程序的可用性较差 Unreliable applications suffer poor availability 可用性、可靠性不同： 可用性是指可以使用，但是不保证正确 可靠性是指可以稳定正确的使用。可用性损失的时间由以下因素决定：Period of loss of availability determined by: 发现故障的时间 Time to detect failure 纠正故障的时间 Time to correct failure 重启应用的时间 Time to restart application例子（时间序）：发生故障-检测到故障-纠正故障-重启应用，这三个代表的是 not available 的时间（N/A） 提高可用性的方案： 尽可能降低 N/A 的时间 机器尽可能缩短 failure 到 detect 时间 机器尽可能缩短 correct 到 restart 的时间 尽可能提高 Available 的时间高可用性策略 Strategies for high availability： 消除单点故障 Eliminate single points of failure 复制和故障转移 Replication and failover 自动检测并重启 Automatic detection and restart可恢复性（例如数据库）Recoverability (e.g., a database): 在应用程序或系统出现故障后，可以重新建立性能级别并恢复受影响的数据的功能。The capability to re-establish performance levels and recover affected data after an application or system failure. 可将可用性计算为在指定的时间间隔内它将在要求的范围内提供指定服务的概率。Availability can be calculated as the probability that it will provide the specified services within required bounds over a specitied time interval. MTBF（平均无故障时间） MTBF (mean time between failures) MTTR（平均维修时间） MTTR (mean time to repair)\[ \frac{MTBF}{MTBF + MTTR} \] 计算可用性时，可能不考虑计划内的停机时间。Scheduled downtimes may not be considered when calculating availability. Outage, Failure, Fault, Error 可用性是指通过减少故障来最大程度地减少服务中断时间。Availability is about minimizing the service outage time by mitigating faults. Failure 的原因称为 Fault。A failure's cause is called a fault. 当系统无法交付该系统期望的服务时，将发生 Failure。A failure occurs when a system cannot deliver a service that is expected of that system. Failure 是系统状态的可观察特征。A failure is an observable characteristics of a system's state. 系统任何部分中的 Fault 都有可能导致 Failure。系统可以从 Failure 中修复或恢复。A fault in any part of a system has a potential to cause a failure; a system can be repaired or recovered from a failure. Fault 发生与 Failure 之间的中间状态称为 Error。Intermediate states between the occurrence of a fault and a failure are called errors.名词辨别： Outage 是系统不可用的情况，scheduled downTime 就是一种 Outage。 Failure：系统不可用失效 Fault：是系统导致 Failure 的原因，Fault 不会立即导致 Failure Error：在 Fault 发生与 Failure 的中间状态。 Service-Level Agreement
Amazon EC2 的 SLA Amazon EC2's SLA: AWS 将通过商业上合理的努力来使 Amazon EC2 在服务年度内的年度正常运行率至少达到 99.95%。如果 Amazon EC2 不符合年度正常运行时间百分比承诺，您将有资格获得服务信用。AWS will use commercially reasonable efforts to make Amazon EC2 available with an Annual Uptime Percentage of at least 99.95% during the Service Year. In the event Amazon EC2 does not meet the Annual Uptime Percentage commitment, you will be eligible to receive a Service Credit. Planning for Failure 危害分析 Hazard analysis: 对 Failure 进行分类 灾难性的/危险 Catastrophic/Hazardous 重大的/轻微的 Major/Minor 没有效果 No effect 故障树分析：Fault tree analysis: 分级处理 Failure
故障模式，影响和严重性分析 Failure Mode, Effects, and Criticality Analysis (FMECA) FMECA 依靠过去类似系统的故障历史。FMECA relies on the history of failure of similar systems in the past. \(5 \times 10^{-5} = 1 \times 10^{-3} \times 5\%\)
ping 和心跳策略在不同的进程中运行，异常策略在单个进程中运行。The ping and heartbeat tactics operate among distinct processes, and the exception tactic operates within a single process. Fault 恢复 Fault Recovery 表决 Voting 在冗余处理器上运行的进程每个都接受等效输入并计算一个简单值，该值将发送给投票者。Processes running on redundant processors each take equivalent input and compute a simple value that is sent to a voter. 如果投票者从单个过程中检测到异常行为，则它会使失败。If the voter detects deviant behaviour from a single process, it fails it. 主动冗余 Active redundancy 所有冗余组件均以并行方式响应事件-所有组件均处于相同状态。All redundant components respond to events in parallel - there are all in the same state. 仅使用了一个组件的响应，其余组件则被丢弃。The response from only one component is used, and the rest are discarded. 发生故障时，通常不存在停机时间，因为备份是最新的，唯一的切换时间是恢复时间。When a failure occurs, the downtime is usually non-existent as backup is current and the only switching time is the recovery time. 被动冗余 Passive redundancy 一个组件（主要）响应事件，并通知其他组件（辅助）它们必须进行的状态更新。One component (primary) responds to events and informs the other components (secondary) of state updates they must make. 发生故障时，系统必须首先确保备份状态足够新，然后才能恢复服务。When a failure occurs, the system must first ensure that the backup state is sufficiently recent before resuming services. 备件 Spare 备用备用计算平台配置为替换许多不同的故障组件。A standby spare computing platform is configured to replace many different failed components. 影子操作 Shadow operation 先前发生故障的组件可能会在“影子模式”下运行一小段时间，以确保它可以模仿工作组件的行为，然后再将其恢复正常工作。A previously failed component may be run in "shadow mode" for a short time to make sure that it mimics the behaviour of the working components before restoring it to service. 状态重新同步 State re-synchronisation 被动和主动冗余策略要求要恢复的组件在恢复服务之前对其状态进行升级。The passive and active redundancy tactics require the component being restored to have its state upgraded before its return to service. 检查点/回滚 Checkpoint/Rollback 检查点记录的是定期或响应特定事件创建的一致状态。A checkpoint is recording of a consistent state created either periodically or in response to specific events. 从服务中删除 Removal from service 该策略将系统的某个组件从运行中移除，以进行一些活动以防止预期的故障。This tactic removes a component of the system from operation to undergo some activities to prevent anticipated failure. 事务 Transaction 事务是几个连续步骤的捆绑，这样就可以一次撤消整个捆绑。A transaction is the bundling of several sequential steps such that the entire bundle can be undone at once. 过程监控器 Process monitor 一旦检测到流程中的故障，监视流程就可以检测到不良流程并为其创建新实例，并按照备用策略将其初始化为适当的状态。Once a fault in a process has been detected, a monitoring process can detect the non-pertorming process and create a new instance ot it, initialised to some appropriate state as in the spare tactic. Checklist for Availability Design & Analysis
Modifiability
可修改性涉及更改以及进行更改所花费的时间或金钱，包括这种可更改性影响其他功能或质量属性的程度。Modifiability deal with change and the cost in time or money of making a change, including the extent to which this modifiability affects other functions or quality attributes.
为变更做准备是有代价的，而进行变更则要付出代价。There is a cost of prepraring for change as well as a cost of making a change.
计划可修改性的四个问题 Four questions to plan for modifiability
有什么可以改变的？What can change?
变化的可能性是多少？What is the likelihood of the change?
何时进行更改，谁进行更改？When is the change made and who makes it?
变更的费用是多少？What is the cost of the change?
如果更改少于预期，则可能不需要昂贵的修改机制。If fewer changes than expected come in, then an expensive modification mechanism may not be warranted.
计算公式：N \(\times\) 不使用机械装置进行更改的成本 \(\leq\) 安装机械装置的成本 +(N 使用机械装置进行更改的成本）
降低的成本可以用于提高可修改性
Modifiability General Scenario
Performance
性能与时间有关，软件与系统满足时序要求的能力有关。（单位时间内能做多少事情） Performance is about time and the software system's ability to meet timing requirements.
所有系统都有性能要求，即使未明确表示也是如此。All systems have pertormance requirements, even it they are not explicitly expressed.
响应时间的两个基本因素 Two basic contributors to the response time
处理时间（系统正在响应时） processing time (when the system is working to response)
阻塞时间（系统无法响应时） blocked time (when the system is una able to response)
Performance General Scenario
Security
安全性衡量系统保护数据和信息免遭未授权访问的能力，同时仍提供对授权人员和系统的访问权限。Security measures system's ability to protect data and information from unauthorized access while still providing access to people and systems that are authorized. 安全性的三个特征：(CIA) Three characteristics of security: (CIA) 机密性，Confidentiality：防止未经授权访问数据和服务。Confidentiality: Data and services are pretected from unauthorized access. 完整性，Integrity：数据和服务不会受到未经授权的操纵。Integrity: Data and services are not subject to unauthorized manipulation. 可用性，Availability：系统将可供合法使用。Availability: The system will be available for legitimate use. Security General Scenario
注意区分：Authenticate：认证，Authorize：授权。 Checklist for Security Design and Analysis
Testability
可测试性是指可以使软件通过（通常基于执行）测试来证明其故障的难易程度。Testability refers to ease with which software can be made to demonstrate its faults through (typically execution-based) testing.
为了使系统能够正确测试，必须有可能控制每个分量 S 的输入，然后观察其输出。For a system to be properly testable, it must be possible to control each component s inputs and then to observe its outputs.
Usability
易用性与用户完成所需任务的难易程度以及系统提供的用户支持的类型有关。Usability is concerned with h how easy it is for the user to accomplish a desired task and the kind of user support the system provides. 易用性包括以下几个方面：Usability comprises the following aspects: 学习系统功能 Learning system features 有效使用系统 Using a system efficiently 最小化错误的影响 Minimizing the impact of errors 使系统适应用户需求 Adapting the system to user's needs 增强信心和满意度 Increasing confidence and satistaction Usability General Scenario
X-ability
|
【本文地址】
今日新闻 |
推荐新闻 |