软件设计
软件设计是软件工程的核心阶段，其目标是将需求转化为可实现的系统结构。根据软件工程理论（如《软件工程：实践者的方法》），软件设计通常包括以下四个独立但相互关联的活动：
1. 数据/类设计（Data/Class Design）
-
目标：定义系统中数据的组织方式及类（对象）的结构。
-
关键任务：
- 识别实体类、边界类和控制类（如MVC模式）。
- 设计类属性、方法及关系（UML类图）。
- 数据库模式设计（如ER模型、表结构）。
-
与其他活动的联系：
- 数据设计影响架构设计（如微服务 vs 单体数据库）。
- 类的方法实现依赖组件级设计。
2. 架构设计（Architectural Design）
-
目标：确定系统的整体结构和高层组件交互方式。
-
关键任务：
- 选择架构风格（如分层架构、微服务、事件驱动）。
- 定义子系统/模块划分及通信机制（如API、消息队列）。
- 处理非功能性需求（性能、可扩展性、安全性）。
-
与其他活动的联系：
- 架构约束接口设计（如REST API规范）。
- 数据存储方案依赖数据设计。
3. 接口设计（Interface Design）
-
目标：规范系统内外部交互的“契约”。
-
关键任务：
- 用户界面（UI） ：设计人机交互流程（如原型图、UX规范）。
- 软件接口（API） ：定义模块/服务间的通信协议（如OpenAPI规范）。
- 硬件接口：与外部设备的数据格式（如IoT传感器协议）。
-
与其他活动的联系：
- 接口是架构设计的具体化（如微服务的API网关）。
- 接口数据格式依赖数据设计。
4. 组件级/过程设计（Component-Level/Procedural Design）
-
目标：细化每个模块或类的具体实现逻辑。
-
关键任务：
- 设计算法和内部流程（如伪代码、流程图）。
- 定义函数/方法的输入、输出及异常处理。
- 优化性能（如缓存策略、并发控制）。
-
与其他活动的联系：
- 组件实现需符合架构设计的约束。
- 方法内部操作依赖数据设计的结构。
关键特点
- 独立性：每个活动关注不同抽象层次（如架构 vs 组件）。
- 协作性：数据设计影响接口，接口约束组件实现。
- 迭代性：设计活动可能反复调整（如发现组件无法满足架构需求时）。
应用场景举例
-
电商系统设计：
- 架构设计：采用微服务（订单服务、支付服务）。
- 数据设计：订单表结构、Redis缓存设计。
- 接口设计：REST API（创建订单、支付回调）。
- 组件设计：订单生成算法的实现（如分布式ID生成）。
这四大活动共同确保软件在宏观和微观层面均具备可维护性、可扩展性和可靠性。
逆向工程（Reverse Engineering）
. 逆向工程的定义与目的
(1) 定义
逆向工程（Reverse Engineering）是指通过分析现有系统的代码、结构或行为，推导出系统的设计、架构或需求的过程。
-
与正向工程对比：
- 正向工程：需求 → 设计 → 实现（传统开发流程）。
- 逆向工程：实现 → 设计 → 需求（反向推导）。
(2) 目的
| 场景 | 逆向工程的作用 |
|---|---|
| 遗留系统维护 | 理解无文档的老系统，避免“黑盒”风险。 |
| 系统重构/现代化 | 将单体架构拆分为微服务，或迁移至云原生架构。 |
| 安全分析 | 分析恶意软件或闭源系统的漏洞（如二进制反编译）。 |
| 竞品分析 | 研究第三方系统的技术实现（需注意法律合规性）。 |
| 考试重点 | 考察架构师对系统分解、模式识别和重构的能力。 |
2. 逆向工程的四个层次
根据抽象程度，逆向工程可分为以下层次：
（1） 实现级 (Implementation Level) 理解系统 “怎么做” 的最底层技术细节。关注代码如何被组织、编写和编译/解释以在特定平台上运行。
（2） 结构级 (Structural Level) 理解系统 “由什么组成” 以及这些组成部分 “如何静态连接” 。关注代码元素之间的静态依赖关系和模块化结构。
（3） 功能级 (Functional Level) 理解系统 “做什么” 。关注系统的外部行为、输入输出转换以及内部组件/模块如何协作来实现功能。
（4） 领域级 (Domain Level) 理解系统 “为什么做” 以及它在特定业务领域中的意义、目的和核心概念。关注系统背后的业务意图、领域知识和约束。
3. 逆向工程的关键技术
(1) 静态分析
- 技术：直接分析源代码或二进制文件，不运行程序。
(2) 动态分析
- 技术：通过运行系统观察行为（如输入/输出、性能）。
(3) 模式识别
-
技术：识别代码中的设计模式或架构风格（如MVC、微服务）。
-
示例：
- 通过代码中的
Controller、Service类推断出分层架构。 - 发现
@FeignClient注解推测使用了Spring Cloud微服务。
- 通过代码中的
4. 逆向工程的典型流程
步骤1：获取系统资产
- 收集源代码、二进制文件、数据库脚本、日志文件等。
- 注意：若为第三方系统，需确保合法性（如遵守许可证）。
步骤2：抽象模型提取
- 代码 → 模型：通过工具生成类图、时序图（如PlantUML）。
- 数据库 → ER图：使用SQL逆向工具（如MySQL Workbench）。
步骤3：架构重构
- 识别“坏味道”（如上帝类、循环依赖）。
- 提出优化方案（如引入防腐层、拆分模块）。
步骤4：文档化
- 输出《系统架构说明书》《重构建议书》。
5. 考试常见题型与答题技巧
(1) 选择题考点
- 逆向工程的适用场景（如“以下哪种情况需要逆向工程？”）。
- 工具匹配（如“反编译Java字节码应使用？” → JD-GUI）。
(2) 案例分析题
-
题目示例：
“某银行遗留系统使用COBOL编写，无完整文档，现需迁移至Java平台。请描述逆向工程的步骤。”
-
答题模板：
- 资产收集：获取COBOL代码、数据库Schema、交易日志。
- 静态分析：使用解析工具提取业务规则（如变量命名反映字段含义）。
- 动态分析：运行测试用例，记录输入/输出映射关系。
- 重构：将COBOL逻辑转换为Java服务，逐步替换。
(3) 论文题
-
可能的题目：
“论遗留系统现代化中的逆向工程与重构技术”。
-
写作要点：
- 结合真实项目经验（如“某政务系统从VB6迁移至.NET”）。
- 强调技术选型（如为何选SonarQube而非人工代码审查）。
6. 注意事项
- 法律风险：反编译商业软件可能违反《著作权法》，需确保授权。
- 伦理问题：考试中需强调“合法合规使用逆向工程”。
- 工具实践：建议实操JD-GUI、PlantUML等工具加深理解。
总结
逆向工程是系统架构师处理遗留系统、优化架构的核心技能，考试中侧重：
- 技术层次（实现级/结构级/领域级）。
- 工具应用（静态分析 vs 动态分析）。
- 案例分析能力（如何从混乱代码中提炼架构）。
掌握这些内容，可有效应对考试中的相关题目！
基于构件的软件工程（Component-Based Software Engineering, CBSE）
基于构件的软件工程（CBSE） 是一种软件开发方法，强调通过可复用的预构建软件构件（Components） 来组装系统，而不是从零开始编写所有代码。CBSE 的核心思想是“组装而非创造”，类似于用乐高积木搭建模型，而不是手工雕刻每个零件。
1. CBSE 的核心概念
(1) 软件构件（Software Component）
-
定义：构件是独立的、可复用的软件单元，具有明确定义的接口和功能。
-
特点：
- 模块化：构件是自包含的，可以独立开发、测试和部署。
- 可复用：可以在不同项目中重复使用，减少开发成本。
- 标准化接口：通过接口（如 API、服务契约）与其他构件交互，隐藏内部实现细节。
- 可替换性：只要接口兼容，构件可以替换或升级而不影响整个系统。
(2) CBSE 的关键原则
- 复用优先：尽可能使用现有构件，而不是重新开发。
- 黑盒复用：使用者只需知道构件的接口，无需了解内部实现。
- 标准化：构件遵循行业标准（如 CORBA、COM/DCOM、EJB、OSGi、Web Services）。
- 松耦合：构件之间通过接口通信，减少依赖关系。
2. CBSE 的开发过程
CBSE 的开发流程与传统软件开发不同，主要包括以下阶段：
(1) 需求分析与构件识别
- 分析系统需求，确定哪些功能可以通过现有构件实现。
- 识别可复用构件（商业构件、开源构件或内部构件）。
(2) 构件评估与选择
- 评估构件的适用性（功能匹配、性能、许可证、成本等）。
- 检查构件的质量（稳定性、兼容性、文档完整性）。
(3) 构件适配与组装
-
如果构件不完全匹配需求，可能需要进行适配（Adaptation） ：
- 白盒适配：修改构件源代码（不推荐，可能影响维护性）。
- 黑盒适配：使用包装器（Wrapper）或适配器（Adapter）调整接口。
-
组装（Composition） ：将构件集成到系统中，通常通过：
- 静态绑定：编译时链接（如 DLL、JAR）。
- 动态绑定：运行时加载（如微服务、插件架构）。
(4) 系统测试与维护
- 测试构件之间的交互，确保整体系统功能正确。
- 维护时，可以单独更新某个构件而不影响整个系统。
3. CBSE 的优势
| 优势 | 说明 |
|---|---|
| 提高开发效率 | 复用现有构件，减少编码工作量，缩短开发周期。 |
| 降低成本 | 避免重复开发，节省人力、时间和资源。 |
| 提高软件质量 | 使用经过验证的成熟构件，减少错误。 |
| 易于维护和升级 | 可以单独替换或升级构件，而不影响整个系统。 |
| 支持分布式开发 | 构件可以独立开发，适合团队协作。 |
4. CBSE 的挑战
| 挑战 | 说明 |
|---|---|
| 构件匹配困难 | 找到完全符合需求的构件可能不容易。 |
| 接口兼容性问题 | 不同构件的接口标准可能不一致，需要适配。 |
| 许可证和法律风险 | 商业构件可能有使用限制或高昂费用。 |
| 性能优化问题 | 复用构件可能导致冗余代码或性能瓶颈。 |
| 系统架构依赖 | 过度依赖第三方构件可能限制系统灵活性。 |
5. CBSE 的应用场景
- 企业应用开发（如 ERP、CRM 系统，使用 SAP、Salesforce 等构件）。
- 嵌入式系统（如汽车电子、工业控制，使用标准化硬件/软件模块）。
- 云计算和微服务架构（如 Docker、Kubernetes 管理可复用服务）。
- 游戏开发（使用 Unity/Unreal 的插件和资源库）。
- Web 开发（如 React/Vue 组件库、NPM 包管理）。
6. CBSE 与相关技术
| 技术 | 与 CBSE 的关系 |
|---|---|
| 面向对象编程（OOP） | CBSE 可以基于 OOP，但构件比类更粗粒度，强调黑盒复用。 |
| 服务导向架构（SOA） | SOA 使用服务（Services）作为构件，通常基于 Web Services 或 REST API。 |
| 微服务架构 | 微服务是 CBSE 的延伸，每个服务是一个独立可部署的构件。 |
| 软件产品线（SPL） | CBSE 可用于构建可配置的产品线，通过不同构件组合生成不同产品。 |
7. 总结
- CBSE 的核心：通过复用预构建的软件构件快速开发系统。
- 关键点：构件标准化、接口定义、适配与组装。
- 优势：提高效率、降低成本、增强可维护性。
- 挑战：构件匹配、接口兼容性、法律风险。
- 适用领域：企业软件、嵌入式系统、云计算、游戏开发等。
CBSE 是现代软件开发的重要方法，尤其在大型系统和快速交付项目中具有显著优势。
统一开发过程（Rational Unified Process, RUP）
统一开发过程（Rational Unified Process, RUP）是一种迭代的软件开发框架，通常分为以下四个主要阶段，每个阶段有明确的目标和里程碑：
-
初始阶段（Inception）
- 目标：确定项目范围和愿景，评估可行性，建立业务案例。
- 关键活动：识别核心需求、主要风险、初步项目计划和高层架构设计。
- 里程碑：达成《生命周期目标》（Lifecycle Objective），决定是否继续项目。
-
细化阶段（Elaboration）
- 目标：细化需求，建立稳定的系统架构，解决高风险问题。
- 关键活动：详细需求分析、设计系统架构、制定开发计划、构建可执行原型。
- 里程碑：达成《生命周期架构》（Lifecycle Architecture），确认架构稳定性和项目计划可行性。
-
构造阶段（Construction）
- 目标：开发完整的系统功能，实现可交付的软件版本。
- 关键活动：编码、测试、集成，完成所有功能模块的开发。
- 里程碑：达成《初始运行能力》（Initial Operational Capability），生成可部署的软件版本。
-
移交阶段（Transition）
- 目标：将系统交付用户，确保产品达到验收标准。
- 关键活动：用户测试（Beta测试）、修复缺陷、培训用户、部署产品。
- 里程碑：达成《产品发布》（Product Release），用户验收并正式上线。
RUP定义了 6种核心工作流（Engineering Workflows）
这些工作流直接与软件开发的技术活动相关：
-
业务建模（Business Modeling）
- 目标：理解业务需求和流程，确保系统与业务目标一致。
- 活动：建立业务用例模型、分析业务流程、定义业务规则。
-
需求（Requirements）
- 目标：捕获和分析用户需求，定义系统功能和非功能需求。
- 活动：识别参与者（Actors）和用例（Use Cases）、编写需求规格说明书（SRS）。
-
分析与设计（Analysis & Design）
- 目标：将需求转化为系统设计，建立可实现的架构。
- 活动：设计类图、组件图、架构模型，制定技术解决方案。
-
实现（Implementation）
- 目标：通过编码和集成实现设计。
- 活动：编写代码、单元测试、组件集成、版本管理。
-
测试（Test）
- 目标：验证系统是否符合需求，确保质量。
- 活动：制定测试计划、执行测试（单元测试、集成测试、系统测试）、缺陷跟踪。
-
部署（Deployment）
- 目标：将系统交付用户并确保其正常运行。
- 活动：安装、配置、用户培训、发布维护计划。
RUP定义了3种支持工作流（Supporting Workflows）
这些工作流贯穿项目全程，提供管理和协调支持：
-
项目管理（Project Management）
- 包括计划制定、风险评估、资源分配、进度跟踪等。
-
配置与变更管理（Configuration & Change Management）
- 管理代码和文档的版本、控制变更请求（如缺陷修复或需求调整）。
-
环境（Environment）
- 为项目提供工具和流程支持（如开发工具、测试框架、文档模板）。
补充说明：
- 迭代性：每个阶段可能包含多次迭代，逐步完善系统。
- 核心工作流：需求、分析设计、实现、测试、部署等活动贯穿各阶段，但侧重点不同。
- 适用场景：RUP常用于中大型复杂项目，强调风险管理和架构驱动。
其他类似模型（如敏捷RUP）可能调整阶段划分，但传统RUP以这四个阶段为核心。
螺旋模型（Spiral Model）的四个阶段
螺旋模型由Barry Boehm提出，是一种风险驱动的迭代开发模型，结合了瀑布模型的系统性和原型模型的灵活性。其核心结构由四个阶段组成，每个迭代周期（螺旋循环）都会经历这四个阶段，逐步完善系统。
1. 目标设定（Planning / Objectives Identification）
-
任务：明确本次迭代的目标、约束条件（如预算、时间）和备选方案。
-
关键活动：
- 确定需求（功能性和非功能性）。
- 识别风险（技术、市场、资源等）。
- 制定初步计划（范围、成本、进度）。
-
输出：项目计划书、风险评估报告。
2. 风险分析与解决（Risk Analysis）
-
任务：评估潜在风险，并制定应对策略。
-
关键活动：
- 识别风险（如技术不可行、需求变更）。
- 评估风险概率和影响（高/中/低）。
- 设计缓解措施（如原型验证、技术预研）。
-
输出：风险清单、应对方案（如放弃高风险功能、调整架构）。
3. 开发与验证（Development & Verification）
-
任务：基于当前迭代目标，开发并测试系统。
-
关键活动：
- 选择开发策略（瀑布式、原型法或增量开发）。
- 实现功能（编码、集成）。
- 验证与测试（单元测试、用户评审）。
-
输出：可交付的增量版本或原型。
4. 评审与规划下一周期（Evaluation & Planning）
-
任务：评估当前迭代成果，决定是否继续或调整方向。
-
关键活动：
- 用户/客户反馈收集。
- 成本与进度复盘。
- 规划下一迭代的优先级（如修复缺陷、新增功能）。
-
输出：迭代总结报告、下一周期计划。
螺旋模型的特点
- 风险驱动：每个迭代优先解决高风险问题。
- 迭代递增：系统功能逐步完善，早期版本可交付用户。
- 灵活适应：适用于需求不明确或技术复杂的项目（如军工、航天）。
- 成本较高：需频繁风险评估和原型开发，适合中大型项目。
与其他模型的对比
- 瀑布模型：线性流程，无迭代；螺旋模型强调动态调整。
- 敏捷模型：均迭代开发，但螺旋模型更强调风险控制，而敏捷侧重快速交付。
通过螺旋模型，团队能在早期发现并解决关键问题，降低项目失败风险。
敏捷方法
1. 四大价值观
- 沟通 强调沟通
- 简单 不过度设计
- 反馈 及时反馈
- 勇气 接收变更
2. 12条过程实践规则
- 简单设计
- 测试驱动
- 代码重构
- 结对编程
- 持续集成
- 现场客户
- 发行版本小型化
- 系统隐喻
- 代码集体所有制
- 规则策略
- 规范代码
- 40小时工作机制
3.常见敏捷开发方法
-
极限编程：价值观 交流、核素、反馈、勇气、近螺旋式的开发方法
-
水晶方法：提倡机动性，快交付，非常敏捷
-
SCRUM：侧重于项目管理，版本迭代。
-
特征驱动开发方法（FDD）：认为有效的软件开发需要3要素 人、过程、技术
-
开方式源码：程序开发人员在地域上分布很广（不强调集中办公）。如：github开源库
需求工程
需求工程分为两个阶段
-
需求开发：需求获取 -> 需求分析 -> 形成需求规格【SRS】 -> 需求确认与验证【形成需求基线（经过评审的SRS）】
-
需求管理：对需求基线的管理。包括变更控制、版本控制、需求跟踪、需求状态跟踪
