分析与设计：确保系统满足利益相关者期望

### 分析与设计：确保系统满足利益相关者期望 #### 1. 分布式系统部署架构定义 在设计分布式系统时，需要根据物理节点及其互连情况来定义部署架构。这一过程包含多个关键步骤： - **分析分布需求**：明确系统对于分布的具体要求程度。 - **定义网络配置**：确定系统的网络连接方式和结构。 - **分配系统元素与负载**：将系统元素分配到各个节点，并合理分布系统的逻辑或物理工作负载。 在这个活动中，技术评审人员负责对架构进行评审。评审过程包括： - **定义评审范围和目标**：明确评审的具体内容和期望达成的目标。 - **遵循特定方法**：根据不同的范围和目标组合，采用相应的评审方法。 - **分阶段评审**：依据项目的阶段和迭代情况进行架构评审，并给出一般性建议。 - **缺陷责任分配**：评审结束后，为每个识别出的缺陷分配责任。 #### 2. 关键工件 分析与设计阶段涉及多种关键工件，以下是对它们的详细介绍： | 工件名称 | 描述 | | --- | --- | | 分析模型 | 定义描述用例实现的对象模型，是设计模型的抽象。它是系统的大致草图，需进一步细化以创建设计模型。 | | 设计模型 | 大多数系统在实现前都应进行设计，以满足实际业务需求并避免因设计错误导致的高昂返工成本。设计模型是分析与设计阶段的主要工件，描述用例的实现，是实现模型及其源代码的抽象，也是实现和测试活动的重要输入。 | | 架构概念验证 | 用于确定是否存在或可能存在满足架构重要需求的解决方案，是对早期识别出的架构重要需求问题的概念性解决方案。 | | 数据模型 | 描述应用程序使用的持久数据的逻辑和物理表示。当应用程序使用关系数据库管理系统（RDBMS）时，还可包含存储过程、触发器、约束等模型元素。 | | 参考架构 | 本质上是预定义的架构模式或模式集，可能部分或完全实例化，适用于特定业务和技术环境，并配有支持工件。 | | 软件架构文档 | 提供软件系统架构的全面概述，使用多种架构视图描述系统的不同方面，是软件架构师与项目团队其他成员之间的重要沟通媒介。 | | 导航图 | 表达系统中主要的用户界面路径，描述系统中用户界面元素的结构及其潜在导航路径。 | | 服务模型 | 是企业内 IT 服务的抽象，支持一个或多个面向服务的解决方案的开发，用于构思和记录软件服务的设计。 | 对于实时系统，还有一些额外的工件： - **胶囊**：代表一种特定的设计模式，在建模和设计高并发系统时很有用，是系统中封装的控制线程，可通过端口与其他胶囊通信，并包含被动类或子胶囊。 - **事件**：指定时间和空间中的发生情况，系统必须对其做出响应，可用于外部和内部事件，如异常。 - **协议**：指定胶囊之间的通信模式，定义一组传入和传出消息类型，可选地包含协作和状态机。 - **信号**：指定从一个对象或实例到另一个对象的异步刺激，可能导致对象状态机的状态转换。 #### 3. 主要角色和职责 分析与设计阶段涉及多个角色，每个角色都有其特定的职责： - **软件架构师**：领导系统软件架构的开发，推动和支持对项目整体设计和实现有约束作用的关键技术决策。其职责和创建的工件如下： ```mermaid graph LR classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; A(软件架构师):::process --> B(描述分布架构):::process A --> C(描述运行时架构):::process A --> D(识别设计机制):::process A --> E(识别设计元素):::process A --> F(整合现有设计元素):::process A --> G(构建架构概念验证):::process A --> H(评估架构概念验证的可行性):::process A --> I(架构分析):::process A --> J(优先排序用例):::process B --> K(架构概念验证):::process C --> K D --> K E --> K F --> K G --> K H --> K I --> K J --> K ```