【系统架构设计】系统分析与设计方法

【系统架构设计】系统分析与设计方法

定义问题与归结模型

问题分析

问题分析的目标是在开发前对要解决的问题有一个更透彻的理解,为达到这个目标,需要经过5个步骤:

  • 在问题定义上达成共识
  • 理解问题的本质
  • 确定项目干系人和用户
  • 定义系统的边界
  • 确定系统实现的约束

因果鱼骨图 + 帕累托图

在理解问题的本质过程中,常使用因果鱼骨图帕累托图两种方法:

  1. 因果鱼骨图

是一种有效的探寻问题根源的技术,它通过直观的图形找出问题或现象的所有潜在原因,从而追踪出问题的根源。它能够帮助人们将问题的原因放在首位,提供了一种运用集体智慧解决问题的方法。在使用时,通常按照以下步骤进行:

  • 将问题简明扼要写在右边的方框里
  • 确定问题潜在原因的主要类别,将它们连到鱼的脊背上
  • 用头脑风暴寻找原因并归类
  1. 帕累托图

是采用直方图的形式,根据问题的相对频率或大小从高往低降序排列,帮助设计师将精力集中在重要的问题上。它可以一目了然显示出各个问题的相对重要程度,有助于预防在解决了一些问题后,却使另外一些问题变得更糟的现象发生。在使用时,通常按照以下步骤进行:

  • 明确问题
  • 找出问题的各种可能原因。通常利用头脑风暴来收集意见,并通过参考以往积累的资料和运营的数据来综合分析
  • 选择评价标准和考察期限。最常用的评价标准包括频率(占总原因的百分之)和费用(产生的影响),而考察的期限则应具有相应问题的代表性,并不是越长越好
  • 收集各种原因发生的频率和费用数据
  • 将原因按照发生的频率或费用从大到小排列起来
  • 将原因排在横轴上,频率或费用排列在纵轴上。

上下文范围图

描述系统的边界有2种方法,一种是结构化分析中的上下文范围图 ,另一种是面向对象分析中的用例模型

  • 上下文范围图,也就是数据流图中的顶层图,它是一个反映领域信息的模型,能够清晰地显示出系统的工作职责和相邻系统的职责起止之处,从而让读者能够从宏观的层面去了解系统。

问题定义

通常包括 目标、功能需求、非功能需求三个方面。

需求分析与软件设计

**软件需求 包括 功能需求、非功能需求、设计约束 ** 三方面内容。

  • 功能需求 : 指系统必须完成的那些事,即为了向它的用户提供有用的功能,产品必须执行的动作
  • 非功能需求:指系统必须具备的属性或品质,如性能、响应时间、可靠性、容错性、扩展性等
  • 设计约束:也成为限制条件、补充规约 ,这通常是对解决方案的一些约束说明,如必须采用国有自主知识版权的数据库系统,必须在UNIX操作系统之下运行等

需求工程 就是包括创建和维护系统需求文档所必需的一切活动的过程,主要包括需求开发需求管理两大工作。

  • 需求开发:包括需求捕获、需求分析、编写规格说明书、需求验证 4个阶段。
  • 需求管理:通常包括定义需求基线、处理需求变更、需求跟踪等方面的工作。

两部分相辅相成,需求开发是主线,是目标;需求管理是支持,是保障 。换句话说,需求开发是努力更清晰、更明确掌握客户对系统的需求,而需求管理则是对需求的变化进行管理的过程

结构化分析与设计

结构化分析

结构化分析方法的基本思想是自顶向下逐层分解分解和抽象是人们控制问题复杂性的两种基本手段。

结构化分析与面向对象分析方法之间最大的差别是:结构化分析方法把系统看作一个过程的集合体,包括人完成的和电脑完成的;而面向对象方法则把系统看成一个相互影响的对象集

ps: 其实就是过程和对象的区别,主要体现在思维方式、代码复用性、系统可维护性、以及系统可扩展性上的区别

  • 思维方式‌:面向过程是一种基于步骤的编程方式,它关注如何通过一系列步骤解决问题,这些步骤通常通过函数来实现,并按照特定的顺序调用。相反,面向对象则是一种基于对象的编程方式,它关注于现实世界中的事物,并将这些事物抽象为对象。对象不仅包含数据,还包含操作这些数据的函数,即方法。这种方式的重点在于通过对象之间的交互来解决问题,而不是通过一系列固定的步骤‌。
  • 代码复用性‌:在面向过程中,如果多个地方需要使用相同的代码段,就必须在多个地方重复编写相同的代码,这不仅增加了代码的冗余,还增加了维护的难度。而在面向对象中,可以通过创建类来实现代码的重用。如果一个类中的方法需要在多个地方使用,只需要在类中定义一次,然后在需要的地方创建该类的对象即可,大大提高了代码的复用性‌。
  • 系统可维护性‌:面向对象的系统由于其高内聚低耦合的特性,使得系统的各个部分相对独立,修改其中一个部分不会影响到其他部分,从而提高了系统的可维护性。此外,面向对象的系统通常具有更好的模块化特性,使得添加新功能或修改现有功能变得更加容易‌
  • 系统可扩展性‌:面向对象的系统由于其基于对象的特性,可以很容易地通过添加新的类或修改现有类来扩展系统的功能。这种灵活性使得面向对象的系统在面对复杂问题时具有更强的适应性和扩展性。相比之下,面向过程的系统在扩展时可能需要大量修改现有的代码逻辑,这增加了系统的复杂性和维护的难度‌

结构化分析方法的特点是利用数据流图来帮助人们理解问题,对问题进行分析。一般包括以下工具:数据流图(Data Flow Diagram ,DFD)、数据字典(Data Dictionary,DD)、结构化语言、判定表、判定树。

DFD

是一种图形化的系统模型,它在一张图中展示信息系统的主要需求,即输入、输出、处理(过程)、数据存储。包括以下基本元素:

  • 过程:也称为加工,一步步执行指令,完成输入到输出的转换
  • 外部实体:也称为源/宿,系统之外的数据源或目的
  • 数据存储:也称为文件,存放数据的地方,一般是以文件、数据库等形式出现
  • 数据流:从一处到另一处的数据流向,如从输入或输出到一个过程的数据流
  • 实时连接:当过程执行时,外部实体和过程之间的来回通信

数据字典技术

涉及到的符号表达如下所示:


结构化设计

结构图

结构图是在需求分析阶段产生的数据流图的基础上进一步的设计,将DFD图中的信息流分为:

  • 交换流 : 信息首先沿着输入通道进入系统,并将其转换为内部表示,然后通过变换中心(加工)的处理,再沿着输出转换为外部形式离开系统。具有这种特性的加工流就是变换流
  • 事务流:信息首先沿着输入通路进入系统,事务中心根据输入信息的类型在若干个动作序列(活动流)中选择一个执行,这种信息流就是事务流

程序流程图和盒图

都是用来描述程序的细节逻辑的,符号如下所示。程序流程图简单、直观、易学 ,但它的缺点也正是由于其随意性而使得画出来的流程图容易变成非结构化的流程图 。而盒图正是为了解决这个问题设计的,是一种符合结构化程序设计原则的图形描述工具,其主要特点是功能域明确、无法任意转移控制、容易确定全局数据和局部数据的作用域、容易表示嵌套关系、可以表示模块的层次结构 ,但缺点是修改相对比较困难

模块设计

模块设计时,最重要的原则就是实现信息隐蔽模块独立 。模块的内聚类型通常可以分为7种,根据内聚度从高到低排序,如下:

ps: 内聚度高 -> 功顺通过 ,瞬逻偶

耦合度从低到高排序 ,如下:

ps: 耦合度高->低 内公外控,标数非

除了信息隐蔽模块独立两大基本原则,通常在模块分解时还需要注意:

  • 保持模块的大小适中,尽可能减少调用的深度,直接调用该模块的个数应该尽量大,但调用其他模块的个数则不宜过大
  • 保证模块是单入口、单出口
  • 模块的作用域应该在控制域内
  • 功能应该是可预测的

面向对象的分析与设计

用户需求经常会发生变化,但客观世界的对象及对象间的关系比较稳定,因此用面向对象方法分析和设计的结构相对比较稳定

对象是系统中用来描述客观事物的一个实体,它由对象标识(名称)、属性(状态、数据、成员变量)、服务(操作、行为、方法) 三个要素组成,它们被封装为一个整体,以接口的形式对外提供服务。

类与对象是抽象描述和具体实例的关系,一个具体的对象被称为类的一个实例

类分为三种类型:

  • 实体类:通常情况下,一定没有属性,但不一定没有操作
  • 控制类:通常情况下,没有属性,但一定有方法
  • 边界类:如窗口、通信协议、打印机接口、传感器和终端等。通常情况下,可以既有属性也有方法。

用户界面设计

设计时必须遵从三个黄金原则

  • 置用户于控制之下
  • 减少用户的记忆负担
  • 保持界面的一致

用户界面的设计过程也应该是迭代的,通常包括4个不同的框架活动

相关推荐
ftswsfb1 天前
【系统架构设计师(第2版)】七、系统架构设计基础知识
系统架构
找了一圈尾巴1 天前
架构师备考-架构基本概念
架构·系统架构
白总Server2 天前
OpenHarmony
后端·spring cloud·华为·微服务·ribbon·架构·系统架构
ftswsfb3 天前
【系统架构设计师】六、UML建模与架构文档化
系统架构·uml
程序猿进阶3 天前
系统上云-流量分析和链路分析
java·后端·阿里云·面试·性能优化·系统架构·云计算
ccino .3 天前
企业级邮件系统架构
系统架构
小云小白4 天前
springboot 传统应用程序,适配云原生改造
云原生·系统架构·k8s·springboot
2401_857617625 天前
Spring Boot框架下的信息学科平台系统架构设计
spring boot·后端·系统架构
0_1_bits6 天前
【系统架构】如何演变系统架构:从单体到微服务
微服务·架构·系统架构
后端从入门到精通6 天前
RUP生命周期架构-系统架构师(八十七)
架构·系统架构