系统架构设计师 需求分析篇二

📘 面向对象分析方法

1. 用例模型 📈

构建用例模型一般需要经历 4 个阶段：

1. 识别参与者 🔍：识别与系统交互的所有事物。
2. 合并需求获得用例 🔗：将需求分配给予其相关的参与者。
3. 细化用例描述 📝：详细描述每个用例的功能。
4. 调整用例模型 🔄：优化用例之间的关系和结构，前三个阶段是必需的。

2. 用例图的三元素 📐

• 参与者 👤：使用系统的用户或其他外部系统和设备。
• 用例 📋：系统所提供的服务。
• 通信关联 🔗：参与者和用例之间的关系，或用例与用例之间的关系。

3. 识别参与者 👥

参与者是与系统交互的所有事物，可以是人、系统、硬件设备或系统时钟。

4. 合并需求获得用例 📚

• 用例命名 📝：采用“动词 + 名词”的形式。
• 区分用例和步骤 🔑：用例是高层次的服务描述，而非具体的操作步骤。
• 业务用例 vs 系统用例 🏢：区分业务需求和系统实现的需求。

5. 调整用例模型 🔄

• 包含 📌：提取公共行为。
• 扩展 🌟：处理多种场景和分支。
• 泛化 📚：抽象共性，形成父用例。

6. 分析模型 🧠

• 静态模型 🏛️：展示对象和类如何组成系统。
• 动态模型 🌀：描述对象和类如何通信，实现系统行为。

7. 确定类之间的关系 🔗

• 关联 🔗：对象实例之间的关系。实线就是代表管线关系，关联体现的是对象实例之间的关系，而不表示两个类之间的关系。
• 依赖 ➡️：一个类的变化可能影响另一个类。虚线就是代表依赖关系，两个类 A 和 B ，如果 B 的变化可能会引起 A 的变化，则称类 A 依赖于类 B。
• 泛化 🔼：特殊性与普遍性的关系，子类继承父类。三角形箭头指向父类，子类继承了父类，子类---->父类，而父类则是子类的普遍性。
• 聚合 📦：类整体与部分的关系，部分可以属于多个整体。“部分”与“整体”的生命周期可以不相同。
• 组合 🔒：整体与唯一部分的关系，生命周期相同。
• 实现 📜：接口与实现的联系。

聚合与组合区分

• 聚合：弱关联－空心菱形－聚合
• 组合：强关联－实心菱形－组合

8. 建立交互图 📊

• 对象 👤：参与交互的实体。
• 参与者 👥：与系统交互的用户或系统。
• 生命线 🧵：对象在交互中的存在时间。
• 激活框 📈：对象在交互中的活跃状态。
• 消息 💬：对象间的通信内容。
• 消息路线 🛤️：消息传递的路径。

9. 系统建模语言 🌐

• SysML：通用系统体系结构建模语言，适用于系统工程应用程序。

UML VS SysML 🆚

UML 局限性 🚫

• 缺少系统级视角。
• 功能描述不全面。
• 缺乏对非功能性需求的描述。

SysUML 优势 ✅

• 提供系统级视角。
• 支持全面性的需求分析。
• 描述复杂系统内部和外部交互。

SysUML 局限性 ⚠️

• 复杂性较高。
• 团队熟悉度需要时间。
• 需要支持SysML的建模工具。

SysML 扩展了一些新的功能机制，如类包、活动包等，新增了 UML 中没有的包，如装配包、需求包、参数包。

10. 总结🧐

• 记忆口诀 🎓：用例模型，像编剧写剧本，参与者是演员，用例是台词，关联是舞台指导。🎭
• 辅助记忆 🧠：
  • 构建用例模型：就像搭建一座城堡，从地基（识别参与者）到塔楼（调整用例模型），每一步都至关重要。
  • 用例图的三元素：参与者是城堡的访客，用例是城堡的房间，通信关联则是连接房间的走廊。
  • 识别参与者：就像在人群中寻找主角，每个与系统互动的都是故事的关键。
  • 合并需求获得用例：将需求像珍珠一样串联起来，形成一条美丽的项链。
  • 调整用例模型：用例模型的园艺，修剪掉多余的枝叶，让结构更加清晰。
  • 分析模型：静态模型是城堡的坚固城墙，动态模型则是城墙内的生活，充满活力。
  • 确定类之间的关系：就像编织一张大网，关联、依赖、泛化、聚合、组合，每一种关系都是网的一部分。
  • 建立交互图：就像导演一场戏，对象是演员，生命线是舞台，消息和消息路线是他们的表演。
  • 系统建模语言：SysML是系统的百科全书，详尽记录了系统的每一个细节。
  • UML与SysML：UML是基础，SysML则是扩展，两者相辅相成，共同构建了系统的宏伟蓝图。

参与点评
读者朋友们,如果您在阅读过程中,对文章的质量、易理解性有任何建议,欢迎在评论区指出,我会认真改进。