战略目标集转化法将信息系统规划看作是一个 {{c1 “信息集合”}} 的构建过程，
- 它从组织的整体战略目标出发，逐级分解并转化为 {{c1 信息系统的战略目标}} ，以保证信息系统建设与组织战略的一致性。
企业系统规划法（BSP）由IBM提出，是一种结构化的信息系统规划方法。
- 它通过自上而下识别 {{c1 企业的战略目标和业务过程}} ，再通过自下而上的 {{c1 数据分析设计信息系统}}，是一种综合性强的方法。
进程通信风格的构件 #card
- 是系统中的独立进程，它们具备自主执行能力，运行于不同的上下文。
连接件：是实现进程间通信的机制，即“消息传递（Message Passing）”。#card
- 它支持进程之间通过发送和接收消息来实现数据交换与协同工作。
- 消息传递方式可以是同步或异步、点对点或广播，也可以是本地或远程的。
常见的业务流程建模方法包括：
- （1）流程图（Flowchart）
- （2）角色活动图与角色交互图
- （3）IDEF0 与 IDEF3
- （4）高级 Petri 网（High-level Petri Net）
- （5）UML 活动图（Activity Diagram）
- （6）业务流程建模标注（BPMN） → 业务流程建模标注，专门用于业务过程建模
事件驱动架构（EDA）是一种典型的 {{c1 异步 }} 通信架构风格，通过事件触发机制实现系统内各模块之间的解耦与异步交互。
- 在这种架构中，各个模块是相互独立的，通过事件 {{c1 通知机制 }} 来实现通信，因此它们之间是非耦合的。
Kernel-based Virtual Machine，是 → 基于Linux内核的虚拟化技术，支持完全虚拟化
Xen → 开源的虚拟机监控器，支持半虚拟化和完全虚拟化，是早期云计算平台常用的虚拟化技术。
Hyper-V → 微软开发的虚拟化平台，是Windows Server中的重要组成部分，用于支持虚拟机的创建和管理。
Linux Virtual Server → 一种负载均衡技术，用于实现集群系统中请求的调度与转发
{{c1 实体完整性 }} 是指数据库中的每个实体（即表的每一行）必须是唯一的，通常涉及主键的设置，确保每条记录的唯一性。
{{c1 参照完整性 }} 是指一个表中的外键值必须对应另一个表的主键值。它用于保持表与表之间的数据一致性。
{{c1 用户定义完整性 }} 是指数据库中可以由用户根据实际业务需求定义的特定规则或约束。
{{c1 系统总线 }} 是 {{c2 连接计算机内部各个部件（如CPU、内存、I/O设备等） }} 的传输通道
{{c1 存储器 }} 是用来存储数据和程序的部件
{{c1 通道 }} 是一种 {{c2 用于管理输入/输出（I/O）操作的控制器 }}
- 通过 {{c1 执行通道程序 }} 来提高CPU和内存与I/O操作之间的 {{c2 并行性 }} 。
- 通道使得 {{c1 I/O操作 }} 不需要占用主机（CPU和内存）资源，从而实现了 {{c1 I/O操作 }} 的并行执行，提升了计算机系统的整体性能。
- 它被称为I/O处理机或I/O控制器，是为了减少CPU与I/O设备之间的 {{c1 直接交互 }} ，增加系统的并行性和效率。
双生命周期模型指的是软件开发中复用技术所支持的两个开发生命周期 #card
- 领域工程（Domain Engineering) 主要负责 → 分析并构建可复用的软件资产（如通用组件、框架等）
- 应用工程（Application Engineering) → 基于这些资产快速构建具体应用
运行期质量属性 #card
- 性能、安全性、可伸缩性、互操作性
开发时期质量属性 #card
- 可重用性、可扩展性、可维护性
可用性 → 衡量系统在多长时间内能够正常运行
易用性 → 关注用户交互的便捷性
性能 → 响应时间相关
SOAP 描述了在消息传递过程中如何使用 {{c1 XML 数据 }} 进行编码，并通过 {{c2 HTTP 或 SMTP }} 等协议进行传输。
SOAP 消息由 {{c1 一个信封、头部（Header）和主体（Body） }} 组成
- 信封 ↔ 定义了消息内容，并指明谁应该处理它们。
共享内存 #card
- 通信中速度最快、结构最简单的一种方式
Socket：#card
- Socket是网络通信接口，通常用于不同主机或进程间的通信
消息传递属于一种更高级的通信方式，通常 {{c1 依赖消息队列或邮箱}} 等机制，有明确的消息边界
信号量是用于 {{c1 任务同步与互斥}} 的机制，不直接用于传递数据
浏览器访问 Web 页面时，#card
- 会先进行域名解析（查询本机缓存或向 DNS 服务器请求），
- 接着在本地网络中可能会通过 ARP 获取网关 MAC 地址，
- 然后建立 TCP 连接，
- 最后才会发出 HTTP 请求报文。
[[SAAM]] 关注于可修改性，使用 {{c1 场景技术}} ，但不使用效用树。
- 是ATAM的前身，主要用于 {{c1 架构比较和场景分析}} 。
B选项[[ATAM]]：#card
- 采用效用树，关注性能、可用性、安全性、可修改性等质量属性，适用于开发前评估，是本题正确答案。
C选项CBAM：#card
- 注重经济价值和ROI评估，虽与质量属性有关，但不直接使用效用树，而是建立在ATAM结果基础上，通过定量分析辅助投资决策。
D选项SAEM：#card
- 属于更通用的[[软件架构评估]]方法，涵盖产品属性和过程属性，但不强调使用效用树。
在架构评估中，基于度量的方法强调通过客观的量化数据对系统进行评价。其核心步骤包括：#card
- 建立映射关系 #card
- 明确系统的质量属性（如性能、可维护性、可靠性等）与具体度量指标之间的映射原则；
- 提取度量信息 #card
- 从架构设计文档、代码结构等资料中提取可度量的信息；
- 推导质量属性水平 #card
- 通过已建立的映射规则，利用采集到的数据推断系统在各个质量属性上的表现水平。
SoC（System on Chip）是一种 {{c1 面向特定应用}} 的集成电路，
- 将系统的关键功能部件集成在单一芯片上，通常包括 {{c1 微处理器、模拟模块、数字模块和存储器}} 等，并配合软件实现完整的系统功能。
论文框架
【摘要】
- 1交代项目背景、项目大致情况，在项目中自己是做什么的（一般是架构师） #card
- 我在_____从事软件架构设计工作，2024年__月，我公司承担了_____项目，该项目目标是要建立一个_____平台，以解决_____等问题。
- 我在这个项目里面，用到了哪些与题目相关的技术 #card
- 为了_____，同时考虑到_____，在项目中，我们设计了_____。为了使_____，架构上，我们采用了_____，抽象了：。同时也制定了，使系统具有高度扩展性，易于_____。
- 项目很成功，客户很开心，老板很开心，我也很开心 #card
- 该项目已经上线 6 个多月，从运行效果来看，达到了预期目的。项目验收时，得到了企业需求方的一致好评。
一、为什么要 xxx #card
- 我现在在哪里工作，职位是XX（100字左右，注意数据脱敏，不要透露完全真实的项目名称和个人、公司信息，用某某代替）
- 1 大势所趋
- 2 好处
- 3 不这么做的坏处
二、项目背景及现状
- 大趋势 #card
- 我有幸参与了该项目的开发，并担任架构师职务，主要负责架构设计及主程序开发的工作。
- 我做了什么项目，业务背景和产品设计是怎么样的（300字左右，同样注意数据脱敏）
- 结合上述背景，该项目有以下难点：#card
- 1、______。
- 2、______。
- 3、______。
三、XXX 详细描述
- 基于上述存在的问题及现状，我们认为，平台的架构必须：#card
- 1、___；
- 2、___
- 3、___
- 说说题目里面的技术或概念是什么（作为论点，300字左右）
- 为了实现上述目的，经过研究和实践，我们采用了___架构，包含：、、、。#card
- 1 ___
- 2 ___
- 3 ___
- 4 ___
- 项目中是怎么体现题目中的技术的（作为论据，也是整片论文的主体部分，1000字左右，举2到4个例子）
四、优劣势分析及后续展望
- 该架构还有以下几个特点：#card
- 1、___；
- 2、___；
- 3、___；
- 项目取得了怎么样的结果，有哪些细小的可以改进的点（结论，400字左右）
- 不足：#card
- 1、___
- 2、___
五、结果 #card
- 该项目上线已经接近半年，从运行效果来看很好的达到了项目预期目标，项目验收时候，得到了有关人员的一致好评。
需求工程中需求管理的核心活动 #card
- 变更控制、
- 版本控制、
- 需求跟踪、
- 需求状态跟踪
不同阶段的具体任务
- 需求描述 ↔ 对需求进行文字化、结构化的表达
- 需求跟踪 ↔ 包括编制每个需求与系统元素之间的联系文档，这些元素包括其它需求、体系结构、设计部件、源代码模块、测试、帮助文件和文档等
- [[需求获取]] ↔ 通过访谈、问卷、观察等方式收集用户需求
- 需求分析 ↔ 用于分析和澄清需求，确定需求的优先级和可行性
Kruchten在1995年提出了一个”4+1”的视图模型。
- “4+1”视图模型从5 个不同的视角来描述 {{c1 软件架构}}
- 每个视图只关心 {{c1 系统的一个侧面}}
- 5 个视图结合在一起才能反映 {{c1 软件架构的全部内容}}
“4+1”的视图模型组成 #card
- 过程视图 ↔ 用于捕捉设计的并发和同步特征
- 过程视图关注系统运行时的行为，特别是线程管理、进程通信、并发处理和同步机制等。它反映了系统的 {{c1 动态结构}} ，适用于多线程和分布式系统的分析。
- 逻辑视图 ↔ 主要描述系统的功能需求和实现，即类、对象等设计元素的组织结构
- 当采用面向对象的设计方法描述对象模型时，通常使 {{c1 类图 }} 表达类的内部属性和行为，以及类集合之间的交互关系
- 开发视图 ↔ 关注代码的组织方式，如模块、包等，属于静态组织结构
- 物理视图、部署视图 ↔ 描述软件组件在硬件上的映射
- 系统软件单元如何映射到硬件资源上，包括节点之间的连接、部署架构、物理拓扑结构等。
- 它体现了系统在物理硬件层面的分布式部署，是“软件→硬件”的直接映射。
- 场景视图、用例视图 ↔ 用于描述系统如何满足用户需求
ATAM（Architecture Tradeoff Analysis Method，架构折中分析法）是由SEI提出的一种系统架构评估方法
- 是在 {{c1 SAAM}} 的基础上发展而来的，
- 主要用于 → 系统开发前对架构设计进行定性分析，
- 评估体系结构是否满足 {{c1 关键质量属性（如性能、可用性、安全性、可修改性等）}}
重点关注的四个属性 #card
- 性能、安全性、可修改性和可用性
核心特征之一就是使用“[[质量属性效用树]]”，它用于：#card
- 对多个质量属性进行分类与排序；
- 将高层次质量目标逐层细化为具体的场景；
- 结合重要性与实现难度，辅助分析架构设计的取舍点（即“折中分析”）。
通过利益相关者头脑风暴方式识别关键场景，这些场景用于评估系统架构在满足质量属性需求（如性能、可用性、可维护性等）方面的能力。典型的三类场景包括
- 用例场景（Use Case Scenario） ↔ 源自最终用户的真实操作，用于验证系统是否满足其核心业务功能。
- 增长情景（Growth Scenario） ↔ 用来模拟系统未来可能发生的变化，例如扩展、升级等，体现架构的可扩展性与可演化性。
- 探索性场景（Exploratory Scenario） ↔ 用于挑战架构极限，例如极端负载或极端故障情形，测试系统鲁棒性与适应能力。
活动阶段 #card
- 需求收集
- 架构视图描述
- 属性模型构造和分析
- 架构决策与折中