系统架构师(八)系统分析与设计方法

定义问题与归结模型

软件系统的目的是为了解决问题,因此在建模之初最重要的步骤是对问题的分析与定义,并在此基础上归结模型,这样才能够获得切实有效的模型。定义问题的过程包括:理解真实世界中的问题和用户的需要,并提出满足这些需要的解决方案的过程。

问题分析

  • 在问题定义上达成共识:
  • 理解问题的本质:
  • 确定项目干系人和用户
  • 定义系统的边界:指解决方案系统和现实世界之间的边界。
    • 上下文范围图:数据流图中的顶层图
    • 用例模型:通过引入参与者来描述“和系统进行交互的事物”
  • 确定系统实现的约束:由于各种因素的存在,会对解决方案的选择造成一定的限制,称这种限制为约束

问题定义

对于一个问题的完整定义,通常应包括目标、功能需求和非功能需求三个方面。

  • 目标:指构建系统的原因,它是最高层次的用户需求,是业务上的需要,而功能、性能需求则必须是以某种形式对该目标做出贡献。
  • 功能需求:用来指明系统必须做的事情,只有这些行为的存在,才有系统存在的价值。
  • 非功能需求:系统必须具备的属性,这些属性可以看作是一些使产品具有吸引力、易用、快速或可靠的特征或属性。
    • 观感需求
    • 易用性需求
    • 性能需求可操作性需求
    • 可维护性和可移植性需求
    • 安全性需求
    • 文化和政策需求
    • 法律需求

需求分析与软件设计

需求分析与软件设计是软件生存期中最重要的两个步骤,需求分析解决的是“做什么”的问题,系统设计则是解决“怎么做”的问题。

理想情况下,每一项用户、业务需求和功能需求都应具备下列性质。
①完整性:每一项需求都必须完整地描述即将交付使用的功能。
②正确性:每一项需求都必须正确地描述将要开发的功能。
③可行性:需求必须能够在系统及其运行环境的已知能力和约束条件内实现。
④必要性:每一项需求记录的功能都必须是用户的真正需要。
⑤无歧义:每一项需求声明对所有读者应该只有一种一致的解释。
⑥可验证性:如果某项需求不可验证,那么判定其实现的正确与否就成了主观臆断。

需求分析

需求分析主要是确定待开发软件的功能、性能、数据、界面等要求。

静态分析通过解析程序文本从而识别出程序语句的各个部分,审查可能的缺陷和异常之处,静态分析包括五个阶段:

  • 控制流分析阶段找出并突出显示那些带有多重出口或入口的循环以及不可达到的代码段;
  • 数据使用分析阶段突出程序中变量的使用情况;
  • 接口分析阶段检查子程序和过程声明及它们使用的一致性;
  • 信息流分析阶段找出输入变量和输出变量之间的依赖关系:
  • 路径分析阶段找出程序中所有可能的路径并画出在此路径中执行的语句。

需求分类:

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

除了这三种需求之外,还有业务需求、用户需求、系统需求这三个处于不同层面的概念

  • 业务需求(Business Requirement):是指反映组织机构或客户对系统、产品高层次的目标要求,通常问题定义本身就是业务需求。
  • 用户需求(User Requirement):是指描述用户使用产品必须要完成什么任务,怎么完成的需求,通常是在问题定义的基础上进行用户访谈、调查,对用户使用的场景进行整理,从而建立从用户角度出发的需求。
  • 系统需求(System Requirement):是从系统的角度来说明软件的需求,它包括用特性说明的功能需求、质量属性、非功能需求及设计约束。

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

  • 需求开发: 包括需求捕获、需求分析、编写规格说明书和需求验证 4 个阶段。
  • 需求管理: 是一个对系统需求变更、了解和控制的过程。通常包括定义需求基线、版本控制、处理需求变更、需求跟踪等方面的工作。

需求分析方法:

  1. 结构化分析方法:
  2. 软系统方法:过渡性的方法论,并未真正流行过
  3. 面向对象分析方法:
  4. 面向问题域的分析(Problem Domain Oriented Analysis,PDOA):还在研究阶段,并未广泛应用。

需求定义与验证

系统架构师(八)系统分析与设计方法_第1张图片
需求验证: 通过需求评审和需求测试,以用户签字确认为验收标准之一

验证准则:

  • 需求是明确的、一致的、无歧义的。
  • 需求是可行的。
  • 需求是可测试的。

软件设计

软件设计(又叫系统设计 )是一个把软件需求变换成软件表示的过程。

  • 概要设计: 也称为高层设计,将软件需求转化为数据结构和软件的系统结构。例如,如果采用结构化设计,则将从宏观的角度将软件划分成各个组成模块,并确定模块的功能及模块之间的调用关系。
  • 详细设计: 也称为低层设计,将对结构表示进行细化,得到详细的数据结构与算法。同样的,如果采用结构化设计,则详细设计的任务就是为每个模块进行设计。

软件设计包括体系结构设计、接口设计、数据设计和过程设计。

  • 结构设计:定义软件系统各主要部件之间的关系。
  • 数据设计:将模型转换成数据结构的定义。好的数据设计将改善程序结构和模块划分,降低过程复杂性。
  • 接口设计(人机界面设计):软件内部,软件和操作系统间以及软件和人之间如何通信。
  • 过程设计:系统结构部件转换成软件的过程描述。

外部设计处于软件设计的开始阶段,主要是按系统需求说明来确定此系统的软件结构和对应于系统需求说明,设计出各个功能部分的功能和接口。
内部设计处于软件工程中的概要设计阶段,按照外部设计中确立的系统软件结构,来细化此系统各个功能部件以及各个部件接口的设计,并且详细给出各个功能部件详细的数据输入、输出设计。内部设计细化外部设计中的各种功能。

结构化分析与设计

结构化分析与设计方法是一种面向数据流的需求分析和设计方法,它适用于分析和设计大型数据处理系统,是一种简单、实用的方法,曾获得广泛的应用。

结构化分析

结构化分析方法的基本思想是自顶向下逐层分解
结构化分析方法的特点是利用数据流图来帮助人们理解问题,对问题进行分析。

结构化分析方法把系统看作一个过程的集合体;而面向对象方法则把系统看成一个相互影响的对象集。

结构化分析一般包括以下工具:数据流图(Data Flow Diagram,DFD)、数据字典(DataDictionary,DD)、结构化语言、判定表、判定树。

结构化方法分析模型的核心是数据字典,围绕这个核心,有三个层次的模型,分别是数据模型、功能模型和行为模型(也称为状态模型)。
在实际工作中,一般使用E-R图表示数据模型,用DFD表示功能模型,用状态转换图表示行为模型。这三个模型有着密切的关系,它们的建立不具有严格的时序性,而是一个迭代的过程。

数据流图

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

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

Context 图。Context 图,也就是系统上下文范围关系图。这是描述系统最高层结构的 DFD 图。它的特点是,将整个待开发的系统表示为一个过程,将所有的外部实体和进出系统的数据流都画在一张图中。
Context 图用来描述系统有什么输入、输出数据流,与哪些外部实体直接相关,可以把整个系统的范围勾画出来。

结构化设计

结构化设计包括架构设计、接口设计、数据设计和过程设计等任务。它是一种面向数据流的设计方法,是以结构化分析阶段所产生的成果为基础,进一步自顶而下、逐步求精和模块化的过程。

概要设计阶段
主要任务是设计软件的结构、确定系统是由哪些模块组成,以及每个模块之间的关系。它采用结构图(包括模块、调用、数据)来描述程序的结构,此外还可以使用层次图和 HIPO(层次图加输入/处理/输出图)。

详细设计阶段
主要任务则是确定应该如何具体地实现所要求的系统,得出对目标系统的精确描述。它采用自顶向下、逐步求精的设计方式和单入口单出口的控制结构。常使用的工具包括程序流程图 PFD、盒图 NS、问题分析图 PAD、程序设计语言 PDL。

  • 结构图: 包括模块、调用(模块之间的调用关系)和数据(模块间传递及处理数据信息)。
  • 程序流程图: 简单、直观、易学
  • 盒图: 功能域明确、无法任意转移控制、容易确定全局数据和局部数据的作用域、容易表示嵌套关系、可以表示模块的层次结构。

程序流程图和盒图都是用来描述程序的细节逻辑的

PAD 是问题分析图的缩写,(自顶向下、逐步求精、结构化程序设计的思想),能够很方便地转换为程序语言的源程序代码。

PDL 是语言描述工具的缩写,包括数据说明部分和过程部分,还可以带注解等成分,但它是不可执行的。PDL 是一种形式化语言,其控制结构的描述是确定的,但内部的描述语法是不确定的。PDL 通常也被称为伪码

模块设计

将一个待开发的软件分解成为若干个小的简单部分——模块,每个模块可以独立地开发、测试。

  • 信息隐蔽原则
  • 模块独立性原则
  • 保持模块的大小适中
  • 减少调用的深度
  • 多扇入少扇出
  • 单入口、单出口
  • 作用域应该在控制域之内
  • 功能可预测

系统架构师(八)系统分析与设计方法_第2张图片

系统架构师(八)系统分析与设计方法_第3张图片

面向对象的分析与设计

基本概念

  • 对象:系统中用来描述客观事物的一个实体(对象标识、属性、方法)
  • 类:对具有相同属性和服务的一个或一组对象的抽象(实体类、边界类和控制类)
  • 继承:说明特殊类(子类)与一般类(父类)的关系
  • 泛化:说明一般类与特殊类的关系(一对多关系)
  • 多态与重载
  • 消息和消息通信

类与对象是抽象描述和具体实例的关系,一个具体的对象被称为类的一个实例。在系统设计过程中,类可以分为三种类型,分别是实体类、边界类和控制类。

  • 实体类:实体类映射需求中的每个实体,实体类保存需要存储在永久存储体中的信息
  • 控制类:控制类是用于控制用例工作的类,控制类用于对一个或几个用例所特有的控制行为进行建模
  • 边界类:边界类用于封装在用例内、外流动的信息或数据流。边界类位于系统与外界的交接处,包括所有窗体、报表、打印机和扫描仪等硬件的接口,以及与其他系统的接口。用于系统接口与系统外部进行交互

统一建模语言

UML的使用

用户界面设计

接口设计主要包括三个方面的内容:一是设计软件构件间的接口;二是设计模块和其他非人的信息生产者和消费者(如外部实体)的接口;三是人(如用户)和计算机间界面设计。

用户界面设计的原则

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

用户界面设计过程(迭代)

  1. 用户、任务和环境分析
  2. 界面设计
  3. 实现
  4. 界面确认

工作流设计

简单分布式计算机应用系统的设计

分布式系统有两种完全不同的方式来进行协同和合作:
1、基于实例的协作 (“ 代理”、远程调用)

  • 请求对象实例可以启动对象、调用远程对象的方法,以及停止运行远程实例。
  • 基于实例的协作适用于比较小范围内网络情况良好的环境中,这种环境常常被称为近连接。

2、基于服务的协作 (接口、采用分层次的结构)

  • 适用于跨平台的网络,网络响应较慢的情况,这种环境常称为 远连接

系统运行环境的集成与设计

软件的运行环境是指系统运行的设备、操作系统和网络配置。

  • 集中式系统:单计算机结构、集群结构(计算机具有类似的硬件平台、操作系统)、多计算机结构(计算机之间操作环境可能不同)
  • 分布式系统:基于网络
  • C/S 结构:由提供服务的服务器和发起请求、接受结果的客户机构成。
  • 多层结构: C/S 结构的扩展,利用中间件实现远程程序调用、对象请求调度等功能。
  • Internet、Intranet 和 Extranet:
    • Internet 是全球的网络集合,使用 TCP/IP 协议。提供电子邮件、文件传输、远程登录等服务。
    • Intranet 是私有网络,只限于内部使用,也使用 TCP/IP协议。
    • Extranet 是一个扩展的 Intranet。它包括企业之外的和企业密切相关合作的其他企业。现在的 VPN技术允许在公用网络上架构只对组织内部开发服务。

系统过渡计划

新开发的系统如何取代旧系统:
1、直接过渡
2、并行过渡
3、阶段过渡

软件系统建模

系统架构师(八)系统分析与设计方法_第4张图片

(1)结构化建模方法
结构化建模方法是以过程为中心的技术可用于分析一个现有的系统以及定义新系统的业务需求,结构化建模方法所绘制的模型称为数据流图(DFD),对于流程较为稳定的系统可使用此方法

(2)信息工程建模方法(数据库建模方法)
信息工程建模方法是一种以数据为中心,但过程敏感的技术,它强调在分析和研究过程需求之前,首先研究和分析数据需求,信息工程建模方法所创建的模型称为实体联系图(ERD),用于数据建模。

(3)面向对象建模方法
面向对象建模方法将“数据”和“过程”集成到“对象”中,消除了数据和过程的人为分离现象,面向对象建模方法所创建的模型称为对象模型,并形成了面向对象的建模标准(UML),目前比较常用的建模方法

你可能感兴趣的:(#,章节学习,需求分析)