📘 面向对象分析方法
1. 用例模型 📈
构建用例模型一般需要经历 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则是扩展，两者相辅相成，共同构建了系统的宏伟蓝图。
参与点评
读者朋友们,如果您在阅读过程中,对文章的质量、易理解性有任何建议,欢迎在评论区指出,我会认真改进。