软件设计师-14,结构化开发方法

系统分析与设计、需求分析、需求工程、结构化分析与设计、测试基础知识、系统运行与维护、软件架构介绍

SA,Structural Analysis,结构化分析

大纲


image-20231006192023655

系统分析与设计


系统分析
  • 系统分析是一种问题求解技术,它将一个系统分解成各个组成部分,自的是研究各个部分如何工作、交互,以实现其系统目标。

  • 目的和任务:系统分析的主要任务是对现行系统进一光步详细调查,将调查中所得到的文档资料集中,对组织内部整体管理状况和信息处理过程进行分析,为系统开发提供所需的资料,并提交系统方案说明书。

  • 主要步骤

    1. 认识、理解当前的现实环境,获得当前系统的“物理模型”。
    2. 从当前系统的“物理模型”抽象出当前系统的“逻辑模型”
    3. 对当前系统的“逻辑模型”进行分析和优化,建立目标系统的“逻辑模型”
    4. 对目标系统的逻辑模型具体化(物理化),建立目标系统的物理模型。
  • 系统开发的目的是将现有系统的物理模型转换为目标系统的物理模型


系统设计
  • 系统设计基本原理:

    • 抽象(重点说明本质方面,忽略非本质方面);
    • 模块化(可组合、分解和更换的单元);
    • 信息隐蔽(将每个程序的成分隐蔽或封装在一个单一的设计模块中);
    • 模块独立(每个模块完成一个相对独立的特定子功能,且与其他模块之间的联系简单。
  • 模块的设计要求独立性高,就必须高内聚,低耦合。

    内聚是指一个模块内部功能之间的相关性,耦合是指多个模块之间的联系。

  • 内聚

    内聚程度从低到高如下表所示

    image-20231006193410602
  • 耦合

    耦合程度从低到高如下表所示

    image-20231006193649617
  • 例题

    image-20231006193923947

    image-20231006194027702


小结
  • 在系统分析阶段,我们已经搞清楚了软件“做什么”的问题,并把这些需求通过规格说明书描述了出来,这也是目标系统的逻辑模型。进入设计阶段,要把软件“做什么”的逻辑模型转换成“怎么做”的物理模型

  • 系统设计的主要目的是为系统制定蓝图,在各种技术和实施方法中权衡利整,精心设计,合理地使用各种资源,得出新系统的详细设计方案。

  • 步骤:概要设计和详细设计

  • 概要设计基本任务:设计软件系统总体结构、数据结构及数据库设计、编写概要设计文档、评审。

  • 详细设计的基本任务:模块内详细算法设计、模块内数据结构设计、数据库的物理设计、其他设计(代码、输入/输出格式、用户界面)、编写详细设计说明书、评审。

  • 系统结构设计原则:分解-协调原则、自顶向下原则、信息隐蔽和抽象原则、一致性原则、明确性原则、模块间高内聚低耦合、模块的扇入系数和扇出系数合理、模块规模适当。

  • 子系统划分的原则:子系统要具有相对独立性、子系统之间数据的依赖性尽量小、子系统划分的结果应使数据几余较小、子系统的设置应考虑今后管理发展的需要、子系统的划分应便于系统分阶段实现、子系统的划分应考虑到各类资源的充分利用。

image-20231006194433212

WebApp的分析与设计


基本概念
  • WebApp是基于Web的系统和应用。大多数WebApp采用敏捷开发过程模型进行开发。

  • WebApp的特性包括网络密集性(服务于不同客户全体的需求)、并发性(大量用户同时访问)、无法预知的负载量(用户数量)、性能(响应时间过长导致用户流失)、可用性(最好7x24x365可用)、数据驱动(与用户的数据交互)。


WebApp五种需求模型:
  1. 内容模型:提供WebApp的全部内容,包括文字、图形、图像、音频和视频。内容模型包含结构元素,为WebApp的内容需求提供了一个重要的视图。这些结构元素包括内容对象和所有分析类,在用户与WebApp交互时生成并操作用户可见的实体。

    • 内容的开发可能发生在WebApp实现之前、构建之中、或者投入运行以后(全过程)。
    • 内容对象:例如产品的文本描述、新闻文章、照片、视频等。
    • 数据树:由多项内容对象和数据项组成的任何内容都可以生成数据树,是内容设计的基础,定义一种层级关系,并提供一种审核内容的方法,以便在开始设计前发现遗漏和不一致的内容。
  2. 交互模型:描述用户与WebApp采用的交互方式。它由一种或多种元素组成,包括用例、顺序图、状态图、用户界面原型等。

    • 用例是交互分析的主要工具,有助于客户理解系统的功能。
    • 顺序图是交互分析中描述用户与系统进行交互的方式,它按照既定顺序展示用户使用系统完成功能的流程,例如登录流程。
    • 状态图是交互分析中对系统进行动态描述的工具,用于展示状态的变化。
    • 用户界面原型展示用户界面的布局、内容、主要导航链接、实施的交互机制以及WebApp的整体美观度。
  3. 功能模型:许多WebApp提供大量的计算和操作功能,这些功能与内容直接相关(例如,能使用数据生成内容,如统计报表)。这些功能通常以用户的交互活动为主要目标。

    • 功能模型定义了用于WebApp内容的操作,并描述了其他处理功能,这些功能不依赖于内容但是最终用户所需的。
  4. 导航模型:为WebApp定义了所有导航策略,考虑了每一类用户如何从一个WebApp元素(例如内容对象)导航到另一个元素。

  5. 配置模型:描述了WebApp所在的环境和基础设施。在必须考虑复杂配置体系结构的情况下,可以使用UML部署图。


WebApp设计
  1. 架构设计:采用多层架构构建,包括用户界面或展示层、基于一组业务规则来指导与客户端浏览器进行信息交互的控制器,以及包含WebApp的业务规则的内容或模型层。这一层面描述了如何管理用户交互、处理内部任务、实现导航以及展示内容的方式。

    • MVC(模型-视图-控制器)结构是WebApp基础结构模型之一,将WebApp的功能和信息内容分离。
  2. 构件设计

    • WebApp构件:定义了良好的聚合功能,为最终用户提供处理内容或提供计算或数据处理功能的聚合包。这些构件提供了最终用户所需的功能。因此,WebApp构件设计通常包括内容设计元素和功能设计元素。
    • 构件级内容设计:侧重于内容对象和以适合WebApp特性的方式展示给最终用户的方式。
    • 构件级功能设计:将WebApp作为一系列构件进行交付,这些构件与信息架构并行开发,以确保一致性。
  3. 内容设计:强调内容对象的表现和导航组织,通常采用线性结构、网格结构、层次结构、网络结构以及它们的组合。

  4. 导航设计:定义导航路径,使用户能够访问WebApp的内容和功能。

软件需求


需求分类
分类 需求类型 描述
从需求内容分类 业务需求 由客户提出的宏观的一个功能需求。
用户需求 设计员去调查需求中涉及到的每个用户的具体需求。
系统需求 经过整合,形成最终的系统需求,包括功能、性能、设计约束三个方面的需求。
从客户角度分类 基本需求 需求明确规定的功能。
期望需求 除了基本需求外,客户认为理所应当包含在内的其他功能。
兴奋需求 客户未要求的其他功能需求,会浪费项目开发时间和成本。
软件需求分类 功能需求 软件必须完成的基本动作。
性能需求 说明软件或人与软件交互的静态或动态数值需求,如系统响应速度、处理速度等。
设计约束 受其他标准硬件限制等方面的影响。
属性 可用性、安全性、可维护性、可转移/转移性。
外部接口需求 用户接口、硬件接口、软件接口、通信接口。

需求工程

六个阶段:

  1. 需求获取:获取需求,方法包括收集资料、联合讨论会(RP)、用户访谈、书面调查、现场观摩、参加业务实践、阅读历史文档、抽样调查。

  2. 需求分析与协商:分析不同人提出的所有需求之间的关系并加以判断。

  3. 系统建模:建立系统的抽象模型。

  4. 需求规约:也即需求定义,主要是为了编写需求规约(即需求规格说明书),在双方之间达成共识。

  5. 需求验证:需求开发阶段的复查手段。需求验证通过后,要请用户签字确认,作为验收标准之一。此时,这个需求规格说明书就是需求基线。

  6. 需求管理:对需求工程涉及的所有过程进行规划和控制。


需求管理
  • 定义需求基线:通过了评审的需求说明书就是需求基线,下次如果需要变更需求,就需要按照流程来一步步进行。

  • 处理需求变更:主要关心需求变更过程中的需求风险管理,带有风险的做法有:无足够用户参与、忽略了用户分类、用户需求的不断增加、模棱两可的需求、不必要的特性、过于精简的SRS、不准确的估算。

  • 需求跟踪:双向跟踪,两个层次,正向跟踪表示用户原始需求是否都实现了,反向跟踪表示软件实现的是否都是用户要求的,不多不少。如下图所示:

    image-20231006201310050

image-20231006201429080

结构化分析


基本概念
  • 结构化分析方法(SA)是一种自顶向下、逐步分解的方法,它面向数据,强调对分析对象的数据流进行建模。在SA中,需要创建以下内容:功能模型(数据流图)、行为模型(状态转换图)、数据模型(E-R图)以及数据字典(包含数据元素、数据结构、数据流、数据存储、加工逻辑和外部实体的定义)。

  • 数据流图描述了数据在系统中如何传输或转换,以及执行数据流转换的功能或子功能。它用于对功能进行建模,以下是与数据流图相关的概念示例:

    image-20231009170932092

数据流图
  • 数据流图可以分为不同层次,从顶层(即上下文级别的数据流图,到0级、1级等)。顶层数据流图只包含一个加工过程,用于表示整个管理信息系统。它描述了系统的输入、输出以及与外部实体的数据交互。以下是数据流图示例:

    image-20231009171135608
  • 设计原则

    1. 数据守恒原则:对于任何一个加工过程,其所有输出数据流中的数据必须能够从该加工过程的输入数据流中直接获得,或者说是通过该加工过程能够产生的数据。
    2. 守恒加工原则:对于同一个加工过程,输入和输出的名称必须不相同,即使它们的组成成分相同。
    3. 每个加工过程必须具有输入数据流和输出数据流。
    4. 外部实体之间不应存在数据流。
    5. 外部实体与数据存储之间不应存在数据流。
    6. 数据存储与数据存储之间不应存在数据流。
    7. 父图与子图的平衡原则:子图的输入和输出数据流必须与父图中相应加工过程的输入和输出数据流一致,以保持父子图之间的平衡。这一平衡原则通常不适用于单一图。
    8. 数据流与加工过程有关,并且必须经过加工过程。

数据字典
  • 数据字典用于定义在数据流图中出现的符号或名称的含义。在数据流图中,每个存储、加工过程和外部实体的含义都必须在数据字典中明确定义,并且图表和子图之间这些名称必须保持一致。

    数据字典用于解释数据流图中各种符号的含义。如果您不清楚某个符号代表的意思,可以查阅数据字典。以下是示例:

    image-20231009181315581

例题

image-20231009181533392

image-20231009181608828

测试基础知识


基本概念
  • 系统测试是为了发现错误而执行程序的过程,成功的测试是发现了至今尚未发现的错误的测试。


测试原则
  • 应尽早且持续地进行测试。

  • 测试工作应该避免由原始开发软件的人员或小组承担。

  • 在设计测试方案时,不仅要确定输入数据,还要根据系统功能确定预期的输出结果。

  • 测试用例既应包括有效且合理的测试案例,也应包括无效和失效的测试案例。

  • 检查程序是否执行了应该执行的操作,同时也要检查程序是否执行了不应该执行的操作。

  • 严格按照测试计划进行测试。

  • 妥善保存测试计划和测试用例。

  • 测试用例可以重复使用或追加测试。


测试阶段
  • 单元测试:对单个模块进行测试,由程序员自行测试模块的内部接口和功能。单元测试以软件详细说明书为依据。在单元测试中,驱动模块(位于上层)用于调用被测模块,而自顶向下单元测试中不需要额外编写驱动模块。桩模块(位于底层)用于模拟被测模块调用的子模块。

  • 集成测试:将模块组合起来进行测试,可分为一次性组装(适用于小型项目,简单,节省时间,错误发现较少)和增量式组装(能够发现更多错误,耗时较长,分为自顶向下、自底向上和混合式)。

  • 验收测试:对已完成的软件进行功能性测试,分为内部确认测试(无用户情境下进行)、Alpha测试(在开发环境下由用户进行测试)、Beta测试(在实际使用环境下由用户进行测试)和验收测试(根据SRS进行验收)。

  • 系统测试:对软件进行性能测试,主要测试三个方面,即负载测试(在极限情况下测试系统的性能指标)、强度测试(在系统资源特别有限的情况下测试)、容量测试(测试系统可以处理的最大同时在线用户数量)。还有其他性能测试,如可靠性测试等。系统测试通常采用黑盒测试方法。


测试方法
  • 动态测试:在程序运行时进行测试,分为:

    • 黑盒测试法:功能性测试,不涉及了解软件代码结构,而是根据功能设计测试用例,以测试软件功能。
    • 白盒测试法:结构性测试,明确了解代码流程,根据代码逻辑设计测试用例,以达到用例覆盖的目的。
    • 灰盒测试法:同时涵盖了黑盒和白盒测试。
  • 静态测试:在程序静止时进行,包括:

    • 桌前检查:程序员自行检查自己编写的程序,在程序编译前和单元测试前进行。
    • 代码审查:由程序员和测试人员组成的评审小组进行,通过召开程序评审会来进行审查。
    • 代码走查:也是通过会议方式对代码进行审查,不仅限于简单的代码检查,还涉及测试人员提供测试用例,程序员扮演计算机的角色手动运行测试用例,检查代码逻辑。

测试策略
  • 测试策略包括以下方式:

    • 自底向上:从最底层模块开始测试,需要编写驱动程序,然后逐渐组装模块,最终完成整个系统的测试。该策略的优点是早期验证底层模块的正确性。
    • 自顶向下:首先测试整个系统,需要编写桩程序,然后逐步下降,逐渐测试最底层模块。该策略的优点是早期验证系统的主要控制和决策点。
    • 三明治测试:结合自底向上和自顶向下的测试方法,兼具两者的优点,但测试工作量较大。

image-20231009185434090

image-20231009185526010


测试用例的设计
  • 黑盒测试用例

    将程序视为黑盒,仅了解输入和输出,不了解内部代码结构。黑盒测试用例设计包括以下几种方法:

    • 等价类划分:把所有的数据按照某种特性进行归类,而后在每类的数据里选取一个即可。

      等价类测试用例的设计原则:设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖的有效等价类。重复这一步,直到所有的有效等价类都被覆盖为止。

      设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类。重复这一步,直到所有的无效等价类都被覆盖为止。

    • 边界值划分:将每个等价类的边界值作为测试用例。边界值通常是范围的两个端点值以及范围之外的两个最接近范围的值。

      比如年龄范围为0-150,那么边界值为:[0, 150, -1, 151] 四个

    • 错误推测:凭经验猜测可能存在问题的地方,然后设计测试用例进行测试。

    • 因果图:通过结果反推原因的方法,具体情况具体分析,没有固定的方法。

  • 白盒测试用例

    知道程序的代码逻辑,按照程序的代码语句,来设计覆盖代码分支的测试用例。白盒测试用例的覆盖级别从低至高可以分为以下六种:

    1. 语句覆盖:确保逻辑代码中的每一条语句都至少被执行一次。尽管这是最低级别的覆盖,但它并不保证所有条件判断都被覆盖。

    2. 判定覆盖:确保逻辑代码中的所有条件判断语句的每个条件的真假分支都被覆盖一次。

    3. 条件覆盖:对于每个条件,包括组合条件(例如:a>0&&b<0),确保每个条件的每个可能的真假组合都被覆盖一次。条件覆盖要求对独立的条件进行真假分支测试,可能会有多个测试用例,比判定覆盖更高级。

    4. 判定/条件覆盖:结合了判定覆盖和条件覆盖,确保每个条件的所有可能取值(真/假)至少出现一次,并且每个判定结果(真/假)也至少出现一次。这是两种覆盖的综合级别。

    5. 条件组合覆盖:确保每个判定条件中的条件各种可能值的组合都至少出现一次。这要求更广泛的测试,以考虑多个条件之间的不同组合。

    6. 路径覆盖:最高级别的覆盖,要求覆盖逻辑代码中的所有可能路径。这意味着每个分支和条件的每个组合都必须被测试,以确保所有可行路径都得到了覆盖。

image-20231009192052220

image-20231009192231901


调试
  • 测试的目的是发现错误,而调试的目的是找出错误的代码和原因。

  • 调试的过程包括确定错误的准确位置、找出问题的原因并设法进行改正。完成调试后,通常需要进行回归测试,以确保修复错误不会引入新的问题。

  • 调试的方法包括:

    • 蛮力法:通过不断尝试不同的解决方案来找到错误。
    • 回溯法:从出错的地方开始,向回追溯代码,逐步查找错误的根本原因。
    • 原因排除法:找出所有可能导致错误的原因,然后逐一排除它们。具体方法包括演绎法、归纳法和二分法。

系统运行与维护


系统转换
  • 系统转换是指将新系统开发完成并投入运行,以取代现有系统的过程。在进行系统转换时,需要考虑多方面的问题,以确保顺利交接旧系统,通常有以下三种转换计划:

    1. 直接转换:新系统直接取代现有系统。这种方法风险较高,适用于新系统简单或现有系统已无法使用的情况。它的优点是能够节省成本。
    2. 并行转换:新系统和旧系统在一段时间内并行运行,新系统经过试运行后再完全取代旧系统。这种方法风险较低,适用于大型系统。在试运行过程中,可以比较新旧系统的性能。然而,这种方法需要投入更多的人力和时间资源,并且需要解决数据转换的问题。
    3. 分段转换:将大型系统划分为多个子系统,逐步转换每个子系统。每个子系统成熟后,就可以转换一个子系统。这种方法适用于大型项目,它将直接和并行转换的优点结合起来。然而,这种方法需要更多的时间,因为现有系统和新系统会混合使用,需要协调接口等问题。
  • 数据转换和迁移是系统转换过程中的关键步骤,它涉及将数据从旧数据库迁移到新数据库中。为了降低迁移的难度,新系统应尽可能地保留旧系统中的合理数据结构。数据迁移通常包括以下三个步骤,也称为ETL(抽取、转换、装载)过程:

    1. 抽取:从旧数据库中提取数据。
    2. 转换:对提取的数据进行转换,这可能包括数据格式的更改、数据清洗等。
    3. 装载:将转换后的数据装入新数据库,并进行数据校验以确保数据的完整性和准确性。

系统维护
  • 软件维护是软件生命周期中的最后阶段,与系统开发过程不同。它是指在软件已经交付并开始使用后,对软件进行修改以纠正错误或满足新需求的过程,也就是对已交付的软件进行任何形式的更改。

  • 系统的可维护性可以定义为维护人员能够理解、更正、修改和改进软件的难易程度。以下是评价可维护性的指标:

    1. 易测试性:涉及确认经过修改的软件是否容易进行测试。
    2. 易分析性:涉及诊断缺陷或失效原因,以及判定需要进行修改的部分是否容易进行分析。
    3. 易改变性:与进行修改、排错或适应环境变化所需努力有关的软件属性。
    4. 稳定性:与修改可能导致未预料的效果风险有关的软件属性。
  • 系统维护包括硬件维护、软件维护和数据维护。其中软件维护方面有以下类型:

    1. 正确性维护:指对已发现的错误(bug)进行修复和修改。
    2. 适应性维护:由于外部环境变化,需要被动地对软件进行修改和升级,以适应新的环境。
    3. 完善性维护:基于用户主动提出的需求,对软件进行修改,增加新功能,提高性能,使其更完善和功能更强大。
    4. 预防性维护:针对可能出现的未来问题,采取预防性的措施和修改,以避免潜在的错误和问题的发生。

image-20231009193435296

image-20231009193548208


系统评价
  • 系统评价分类

    1. 立项评价:在系统开发之前进行的初步评价,用于分析是否值得立项开发,并进行可行性评估。
    2. 中期评价:项目开发过程中的定期评估,包括每个阶段的阶段评审,以及在开发过程中遇到重大变化时的评估,以确定是否需要继续进行项目开发。
    3. 结项评价:在系统正式投入运行后进行的综合评估,以了解系统是否达到了预期的目标和要求。
  • 系统评价的指标

    1. 运行效果:评估系统的运行效果,包括用户满意度和系统的实际运行质量。
    2. 用户需求:关注用户对系统的需求是否得到满足,包括功能需求和性能需求。
    3. 系统质量:评估系统的质量和技术水平,包括系统的稳定性、可维护性和可扩展性等方面。
    4. 技术条件:考察系统的技术条件和技术水平,包括技术架构、开发工具和技术标准等。
    5. 社会效益:评估系统对外部环境的影响,包括社会效益和环境效益等。
    6. 系统成本:考察系统的开发和维护成本,包括人力成本、硬件成本和软件成本等。
    7. 系统效益:评估系统的效益,包括经济效益、业务效益和用户效益等。
    8. 财务指标:关注系统的财务指标,包括投资回报率(ROI)、成本效益分析和财务风险等。

image-20231009194220890