系统分析与设计

TTT_ZY

于 2024-02-20 20:01:32 发布

阅读量707

点赞数 5

文章标签： uml 系统架构

本文链接：https://blog.csdn.net/TTT_ZY/article/details/136195518

版权

什么是系统

系统是由一组实体和这些实体之间的关系所构成的集合，其功能要大于这些实体各自的功能之和。对于我们的场景，系统可能是 App、Web 应用、服务、批处理程序等，也可能是包括所有这些的一个大系统。

系统设计流程

产品原型（做什么产品）
分析模型（业务上怎么做）
架构设计（技术上怎么做）
代码实现（开干）
业务分析，主要处理的是业务领域的建模。解决的问题是业务上如何实现。然后是技术与架构方面的设计，主要针对的是技术实现，解决的问题是技术上如何实现。这两个方面是会互相影响的，设计的时候往往需要来来回回的考虑这两个方面。甚至系统开发时也时常会需要调整模型或者架构，当然相应的也需要更新文档。

基本原则

设计与分析的过程就是不停的进行抽象和封装，并且确定各个系统实体的细节。抽象是指将业务抽象为软件领域的元素（系统、模块或类）；封装则是指定义元素的边界，隐藏实现，开放接口。
相应的，分析与设计时，最基本的原则就是抽象性和封装性。当然，我们有 SOLID、DRY、高内聚低耦合、设计模式等各种原则和方法，具体方式本文不详述了，但最终它们都可以归类到以上两点。

业务分析

分析方法
业务分析是针对业务领域的建模，产出就是分析模型。分析模型描述系统的逻辑设计与结构，一般会包括需求用例、实体模型以及业务场景的交互流程、状态转换等。分析模型让非技术人员能够理解系统是如何构造的，让技术人员能够以此为基础搭建系统。
分析的过程是不断迭代的。特别对于复杂的、涉及多个业务领域的需求，第一步往往需要在整体系统的层级进行分析，然后将模型划分到多个子系统，然后再在子系统的层级进行更细节的分析与建模。
另一方面，分析过程中需要不断的优化和调整。例如在确定实体的行为细节时，发现两个实体的耦合很高，那么可能需要重新进行抽象，调整实体的功能范围。
理清业务需求
理清业务需求是所有分析与设计的前提：
- 确定系统的利益相关者（Stakeholder）及他们的关注点。
- 确定系统的业务需求，即「谁」使用该系统「做什么」。
- 确定系统的功能范围，即该系统「包含什么」，不包含「什么」。
  系统需要满足利益相关者的关注点，所以要确保所有这些关注点都有涉及到。最重要的利益相关者当然就是用户（有时还会细分为不同类型的用户），此外还应该包括供应商、合作方、运营、销售、老板甚至政府等等，也同样包括研发测试和运维。
  具体到系统的用户，还需要细分到角色，即使有些角色实际可能是同一个人。比如对于门诊，可能有护士、顾问或系统管理员等等，可以进行不同的操作。需求范围简单话用一个列表即可，复杂的系统可以考虑使用用例图。
建立实体模型
实体模型是确定系统包含的实体以及它们之间的关联的过程：
– 理清业务概念，统一业务词汇。
– 抽象业务实体，包括事件、人/角色、地点和事物等。
– 识别实体关系：继承、聚合、关联等。
实体模型也叫 ER（Entity-Relation）模型。可以考虑使用四色法建模，一般可以使用类图或组件图表示。需要注意的是一定要理清业务的概念，统一命名和定义业务相关词汇，这是进一步沟通的基础。
分析业务场景
场景分析用于确定具体业务场景中，各个参与者的交互过程，从而进一步完善分析模型：
– 分析具体业务场景，确定业务规则，梳理业务流程。
– 如果涉及复杂的状态转换，需要确定状态转换逻辑。
– 补充和完善实体模型的内容描述。
对于一个业务场景，参与者可能包括人、内部模块、外部服务等，这一步需要理清楚整个业务过程和规则。需要注意的是，对于一些次要路径或者异常路径，也一定要考虑到。对于业务过程和规则，可以使用普通的流程图、泳道图，也可以考虑UML的活动图，状态转换过程则可以通过UML的状态图展示。
对于场景分析中不太确定的需求，或者可能会有技术难点地方，可以记录下来，后面确认和验证。