5软件工程基础知识(1)

软件工程（8分）：29~36题

• 软件过程

  在开发产品或构建系统时，遵循一系列可预测的步骤（即路线图）是非常重要的，它有助于及时交付高质量的产品。软件开发中所遵循的路线图称为“软件过程”。过程是活动的集合，活动是任务的集合。软件过程有3层含义：一个是个体含义，即指软件产品或系统在生存周期中的某一类活动的集合，如软件开发过程、软件管理过程等：二是整体含义，即指软件产品或系统在所有上述含义下的软件过程的总体：三是工程含义，即指解决软件过程的工程，应用软件的原则、方法来构造软件过程模型，并结合软件产品的具体要求进行实例化，以及在用户环境下的运作，以此进一步提高软件的生产率，降低成本。

  • 能力成熟度模型（CMM）

    在美国国防部的支持下，1987年，卡内基·梅隆大学软件工程研究所率先推出了软件工程评估项目的研究成果一软件过程能力成熟度模型（Capability Maturity Model of Software,CMM),其研究目的是提供一种评价软件承接方能力的方法，同时它可帮助软件组织改进其软件过程。

    • 初始级(Initial)

      • 软件过程的特点是杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤，项目的成功完全依赖个人的努力和英雄式核心人物的作用。

    • 可重复级(Repeatable)

      • 建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功。

    • 已定义级(Defined)

      • 管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件。

    • 已管理级(Managed)

      • 制定了软件过程和产品质量的详细度量标准。软件过程的产品质量都被开发组织的成员所理解和控制。

    • 优化级(Optimized)

      • 加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。

  • 能力成熟度模型集成（CMMI）

    CM的成功导致了适用不同学科领域的模型的衍生，如系统工程的能力成熟度模型，适用于集成化产品开发的能力成熟度模型等。而一个工程项目又往往涉及多个交叉的学科，因此有必要将各种过程改进的工作集成起来。1998年，由美国产业界、政府和卡内基·梅隆大学软件工程研究所共同主持CMMI项目。CMMI是若干过程模型的综合和改进，是支持多个工程学科和领域的、系统的、一致的过程改进框架，能适应现代工程的特点和需要，能提高过程的质量和工作效率。2000年发布了CMMI-SE/SW/IPPD,集成了适用于软件开发的SW-CMMI(草案版本2©)、适用于系统工程的EIA/IS731以及适用于集成化产品和过程开发的IPD CMM(0.98版)。2002年1月发布了CMMI-SE/SW/IPPD1.1版。

    • 阶段式模型

      • 初始的

        • 过程不可预测且缺乏控制

      • 己管理的

        • 过程为项目服务

      • 己定义的

        • 过程为组织服务

      • 定量管理的

        • 过程已度量和控制

      • 优化的

        • 集中于过程改进

    • 连续式模型

      连续式模型关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级(Capability Level,CL)。CMMI中包括6个过程域能力等级，等级号为0~5。能力等级包括共性目标及相关的共性实践，这些实践在过程域内被添加到特定目标和实践中。当组织满足过程域的特定目标和共性目标时，就说该组织达到了那个过程域的能力等级。

      能力等级可以独立地应用于任何单独的过程域，任何一个能力等级都必须满足比它等级低的能力等级的所有准则

      • CL0（未完成的）

        • 过程域未执行或未得到CL1中定义的所有目标。

      • CL1（已执行的）

        • 其共性目标是过程将【可标识】的输入工作产品转换成【可标识】的输出工作产品，以实现支持过程域的特定目标。

      • CL2（己管理的）

        • 其共性目标集中于【己管理】的过程的制度化。根据组织级政策规定过程的运作将使用哪个过程，项目遵循己文档化的计划和过程描述，所有正在工作的人都有权使用足够的资源，所有工作任务和工作产品都被监控、控制和评审。

      • CL3（已定义级的）

        • 其共性目标集中于【己定义】的过程的制度化。过程是按照组织的剪裁指南从组织的标准过程集中剪裁得到的，还必须收集过程资产和过程的度量，并用于将来对过程的改进。

      • CL4（定量管理的）

        • 其共性目标集中于【可定量管理】的过程的制度化。使用测量和质量保证来控制和改进过程域，建立和使用关于质量和过程执行的定量目标作为管理准则。

      • CL5（优化的）

        • 使用量化（统计学）手段【改变和优化过程域】，以满足客户要求的改变和持续改进计划中的过程域的功效。

  • 软件过程模型（软件开发模型）

    它是软件开发全部过程、活动和任务的结构框架。

    • 瀑布模型【Waterfall Model】

      • 定义

        • 瀑布模型是将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型，包括需求分析、设计、编码、测试、运行与维护。它规定了由前至后、相互衔接的固定次序，如同瀑布流水逐级下落

      • 结构

        • 

      • 优点

        • 容易理解，管理成本低
        • 强调开发的阶段性早期计划及需求调查和产品测试

      • 缺点

        • 客户必须能够完整、正确和清晰地表达他们的需要
        • 在开始的两个或3个阶段中，很难评估真正的进度状态
        • 当接近项目结束时，出现了大量的集成和测试工作
        • 直到项目结束之前，都不能演示系统的能力
        • 在瀑布模型中，需求或设计中的错误往往只有到了项目后期才能够被发现，对于项目风险的控制能力较弱，从而导致项目常常延期完成，开发费用超出预算

      • 适用性

        • 对项目领域熟悉
        • 开发与曾经项目相似
        • 需求和目标明确清晰
        • 后期不再添加需求，不变更

      • 变体

        • V模型

          • 定义

            • V模型描述了质量保证活动和沟通、建模相关活动以及早期构建相关的活动之间的关系。随着软件团队工作沿着V模型左侧步骤向下推进，基本问题需求逐步细化，形成问题及解决方案的技术描述。一旦编码结束，团队沿着V模型右侧的步骤向上推进工作，其实际上是执行了一系列测试（质量保证活动），这些测试验证了团队沿着V模型左侧步骤向下推进过程中所生成的每个模型。V模型提供了一种将验证确认活动应用于早期软件工程工作中的方法。

          • 结构

            • 

        • 增量模型【Incremental Model】

          • 定义

            • 增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，它假设可以将需求分段为一系列增量产品，每一增量可以分别开发。该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”，如图5-4所示。当使用增量模型时，第1个增量往往是【核心】的产品。客户对每个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。

              • 先做核心雏形，再一点点逐步开发，不断加需求

          • 结构

            • 

          • 优点

            • 具有瀑布模型所有优点
            • 第一个可交付版本所需要的成本和时间很少
            • 开发由增量表示的小系统所承担的风险不大
            • 由于很快发布了第一个版本，因此可以减少用户需求的变更
            • 运行增量投资，即在项目开始时，可以仅对一个或两个增量投资

          • 不足

            • 如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定
            • 如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布
            • 管理发生的成本、进度和配置的复杂性可能会超出组织的能力

    • 演化模型【Evolutionary Model】

      软件类似于其他复杂的系统，会随着时间的推移而演化。在开发过程中，常常会面临以下情形：
      1.商业和产品需求经常发生变化，直接导致最终产品难以实现；
      2.严格的交付时间使得开发团队不可能圆满地完成软件产品，但是必须交付功能有限的版本以应对竞争或商业压力；
      3.很好地理解了核心产品和系统需求，但是产品或系统扩展的细节问题却没有定义。在上述情况和类似情况下，软件开发人员需要一种专门应对不断演变的软件产品的过程模型。

      演化模型是迭代的过程模型，使得软件开发人员能够逐步开发出更完整的软件版本。演化模型特别适用于对软件需求缺乏准确认识的情况。典型的演化模型有原型模型和螺旋模型等。

      • 原型模型【Prototype Model】

        并非所有的需求都能够预先定义，大量的实践表明，在开发初期很难得到一·个完整的、准确的需求规格说明。这主要是由于客户往往不能准确地表达对未来系统的全面要求，开发者对要解决的应用问题模糊不清，以至于形成的需求规格说明常常是不完整的、不准确的，有时甚至是有歧义的。
        此外，在整个开发过程中，用户可能会产生新的要求，导致需求的变更。而瀑布模型难以适应这种需求的不确定性和变化，于是出现了快速原型(Rapid Prototype)这种新的开发方法。原型方法比较适合于用户需求不清、需求经常变化的情况。当系统规模不是很大也不太复杂时，采用该方法比较好。

        • 介绍

          • 原型模型开始于沟通，其目的是定义软件的总体目标，标识需求，然后快速制订原型开发的计划，确定原型的目标和范围，采用快速设计的方式对其进行建模，并构建原型。被开发的原型应交付给客户使用，并收集客户的反馈意见，这些反馈意见可在下一轮中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发。

        • 结构

          • 

        • 适用性

          • 用户对需求不是很熟悉
          • 用户需求经常变化
          • 系统规模不是很大也不太复杂
          • 根据用户意见修改模型
          • 快速、低成本地构建原型
          • 有效捕获系统需求

      • 螺旋模型【Spiral Model】

        • 对于复杂的大型软件，开发一个原型往往达不到要求。螺旋模型将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析，弥补了这两种模型的不足。

        • 螺旋周期

          • (1)制订计划

            • 确定软件的目标，选定实施方案，明确项目开发的限制条件

          • (2)风险分析

            • 分析所选的方案，识别风险，消除风险

          • (3)实施工程

            • 实施软件开发，验证阶段性产品

          • (4)用户评估

            • 评价开发工作，提出修正建议，建立下一个周期的开发计划

        • 结构

          • 

        • 适用性

          • 螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，从而做出应有的反应。因此，该模型特别适用于庞大、复杂并且具有高风险的系统。

        • 优点

          • 与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高软件的适应能力，并且为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发的风险。

        • 不足

          • 在使用螺旋模型进行软件开发时，需要开发人员具有相当丰富的风险评估经验和专门知识
          • 过多的迭代次数会增加开发成本，延迟提交时间

    • 喷泉模型【Water Fountain Model】

      • 定义

        • 喷泉模型是一种以【用户需求为动力，以对象作为驱动】的模型，适合于面向对象的开发方法。
        • 它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。
        • 喷泉模型使开发过程具有迭代性和无间隙性，如图5-7所示。迭代意味着模型中的开发活动常常需要重复多次，在迭代过程中不断地完善软件系统。
        • 【无间隙】是指在开发活动(如分析、设计、编码)之间不存在明显的边界，也就是说，它不像瀑布模型那样，在需求分析活动结束后才开始设计活动，在设计活动结束后才开始编码活动，而是允许各开发活动交叉、迭代地进行。
        • 喷泉模型的各个阶段没有明显的界线，开发人员可以同步进行。

      • 结构

        • 

      • 优点

        • 可以提高软件项目的开发效率，节省开发时间

      • 不足

        • 由于喷泉模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，不利于项目的管理。
        • 这种模型要求严格管理文档，使得审核的难度加大。

    • 统一过程模型【Unified Process Model】

      • 定义

        • 统一过程模型是一种“用例和风险驱动，以架构为中心，迭代并且增量”的开发过程，由UML方法和工具支持。
        • 迭代的意思是将整个软件开发项目划分为许多个小的“袖珍项目”，每个“袖珍项目”都包含正常软件项日的所有元素：计划、分析和设计、构造、集成和测试，以及内部和外部发布。

      • 4个技术阶段

        • 1)起始阶段(Inception Phase)

          • 起始阶段专注于项目的初创活动

            • 生命周期目标

          • 工作产品

            • 构想文档(Vision Document)
            • 初始用例模型
            • 初始项目术语表
            • 初始业务用例
            • 初始风险评估
            • 项目计划（阶段及迭代）
            • 业务模型
            • 一个或多个原型（需要时）

        • 2)精化阶段(Elaboration Phase)

          • 精化阶段在理解了最初的领域范围之后进行需求分析和架构演进

            • 生命周期架构

          • 工作产品

            • 用例模型

            • 补充需求（包括非功能需求）

            • 分析模型

            • 软件体系结构描述

            • 可执行的软件体系结构原型

            • 初步的设计模型

            • 修订的风险列表

            • 项目计划

              • 迭代计划
              • 调整的工作流
              • 里程碑
              • 技术工作产品

            • 初始用户手册

        • 3)构建阶段(Construction Phase)

          • 构建阶段关注系统的构建，产生实现模型

            • 初始运作功能

          • 工作产品

            • 设计模型

            • 软件构件

            • 集成的软件增量

            • 测试计划及步骤

            • 测试用例

            • 支持文档

              • 用户手册
              • 安装手册
              • 对于并发增量的描述

        • 4)移交阶段(Transition Phase)

          • 移交阶段关注于软件提交方面的工作，产生软件增量

            • 产品发布

          • 工作产品

            • 提交的软件增量
            • β测试报告
            • 综合用户反馈

      • 5个工作流

        • 捕获系统应该做什么的需求工作流
        • 精化和结构化需求的分析工作流
        • 在系统构架内实现需求的设计工作流
        • 构造软件的实现工作流
        • 验证实现是否如期望那样工作的测试工作流

      • 统一过程的典型代表是RUP(Rational Unified Process)。RUP是UP的商业扩展，完全兼容UP,但比UP更完整、更详细。

        • RUP应用了角色、活动、制品和工作流4种重要的模型元素

        • 角色

          • “谁做”

        • 制品

          • “做什么”

        • 活动

          • “怎么做”

        • 工作流

          • “什么时候做”

    • 敏捷方法【Agile Development】

      • 定义

        • 敏捷开发的总体目标是通过“尽可能早地、持续地对有价值的软件的交付”使客户满意。通过在软件开发过程中加入灵活性，敏捷方法使用户能够在开发周期的后期增加或改变需求。
        • 敏捷过程的典型方法有很多，每一种方法基于一套原则，这些原则实现了敏捷方法所宣称的理念（敏捷宣言）。

      • 类型

        • 1.极限编程（XP)

          • 定义

            • XP是一种轻量级（敏捷）、高效、低风险、柔性、可预测的、科学的软件开发方式。它由价值观、原则、实践和行为4个部分组成，彼此相互依赖、关联，并通过行为贯穿于整个生存周期。

          • 4大价值观

            • 沟通
            • 简单性
            • 反馈
            • 勇气

          • 5个原则

            • 快速反馈
            • 简单性假设
            • 逐步修改
            • 提倡更改
            • 优质工作

          • 12个最佳实践

            • 计划游戏(快速制定计划、随着细节的不断变化而完善)
            • 小型发布（系统的设计要能够尽可能早地交付）
            • 隐喻（找到合适的比喻传达信息）
            • 简单设计(只处理当前的需求，使设计保持简单)
            • 测试先行(先写测试代码，然后再编写程序)
            • 重构(重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求)
            • 结队编程
            • 集体代码所有制
            • 持续集成（可以按日甚至按小时为客户提供可运行的版本）
            • 每周工作40个小时
            • 现场客户
            • 编码标准

        • 2.水晶法(Crystal)

          • 水晶法认为每一个不同的项目都需要一套不同的策略、约定和方法论，认为人对软件质量有重要的影响，因此随着项目质量和开发人员素质的提高，项目和过程的质量也随之提高。通过更好地交流和经常性的交付，软件生产力得到提高。

        • 3.并列争求法(Scrum)

          • 并列争求法使用迭代的方法，其中，把每30天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。多个自组织和自治的小组并行地递增实现产品。协调是通过简短的日常情况会议来进行，就像橄榄球中的“并列争球”。

        • 4.自适应软件开发(ASD)

          • ASD有6个基本的原则

            • 有一个使命作为指导
            • 特征被视为客户价值的关键点
            • 过程中的等待是很重要的，因此“重做”与“做”同样关键
            • 变化不被视为改正，而是被视为对软件开发实际情况的调整
            • 确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求
            • 风险也包含其中

        • 5.敏捷统一过程(AUP)

          • 定义

            • 敏捷统一过程(Agile Unified Process,AUP)采用“在大型上连续”以及在“在小型上迭代”的原理来构建软件系统。采用经典的UP阶段性活动(初始、精化、构建和转换)，提供了一系列活动，能够使团队为软件项目构想出一个全面的过程流。在每个活动里，一个团队迭代使用敏捷，并将有意义的软件增量尽可能快地交付给最终用户。每个AUP迭代执行以下活动：

          • 建模

            • 建立对商业和问题域的模型表述，这些模型“足够好”即可，以便团队继续前进

          • 实现

            • 将模型翻译成源代码

          • 测试

            • 像XP一样，团队设计和执行一系列的测试来发现错误以保证源代码满足需求

          • 部署

            • 对软件增量的交付以及获取最终用户的反馈

          • 配置及项目管理

            • 着眼于变更管理、风险管理以及对团队的任一制品的控制。项目管理追踪和控制开发团队的工作进展并协调团队活动

          • 环境管理

            • 协调标准、工具以及适用于开发团队的支持技术等过程基础设施

    • 基于构件的开发模型【Component-based Development Model】

      • 基于构件的开发是指利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件，也可以是商品化成品(Commercial Off-The-Shelf,COTS)软件构件。基于构件的开发模型具有许多螺旋模型的特点，它本质上是演化模型，需要以迭代方式构建软件。其不同之处在于，基于构件的开发模型采用预先打包的软件构件开发应用系统。

      • 一种基于构建的开发模型如图5-8所示，包括领域工程和应用系统工程两部分。

        • 

      • 领域工程的目的是构建领域模型、领域基准体系结构和可复用构件库。为达到此目的，首先要进行领域分析，分析该领域中各种应用系统的公共部分或相似部分，构建领域模型和领域基准体系结构，表示领域的候选构件，对候选构件进行可变性分析，以适应多个应用系统的需要，最后构建可复用构件，经严格测试和包装后存入可复用构件库。

      • 应用系统工程的目的是使用可复用构件组装应用系统。首先进行应用系统分析，设计应用系统的体系结构，标识应用系统所需的构件，然后在可复用构件库中查找合适的构件（也可以购买第三方构件），这些选取的构件需进行特化，必要时做适当的修改，以适应该应用系统的需要。对于那些未找到合适构件的应用部分，仍需单独开发，并将其与特化修改后的构件组装成应用系统。在此过程中，还需要对可复用构件的复用情况进行评价，以改进可复用构件，同时对新开发的部分进行评价，并向领域工程推荐候选构件。

    • 形式化方法模型【Formal Methods Model】

      • 形式化方法是建立在严格数学基础上的一种软件开发方法，其主要活动是生成计算机软件形式化的数学规格说明。
      • 形式化方法用严格的数学语言和语义描述功能规约和设计规约，通过数学的分析和推导，易于发现需求的歧义性、不完整性和不一致性，易于对分析模型、设计模型和程序进行验证。通过数学的演算，使得从形式化功能规约到形式化设计规约，以及从形式化设计规约到程序代码的转换成为可能。这种方法的一个变形是净室软件工程。

• 需求分析

  • 软件需求

    • (1)功能需求

      • 考虑系统要做什么，在何时做，在何时以及如何修改或升级。

    • (2)性能需求

      • 考虑软件开发的技术性指标。例如，存储容量限制、执行速度、响应时间及吞吐量。

    • (3)用户或人的因素

      • 考虑用户的类型。例如，各种用户对使用计算机的熟练程度，需要接受的训练，用户理解、使用系统的难度，用户错误操作系统的可能性等。

    • (4)环境需求

      • 考虑未来软件应用的环境，包括硬件和软件。对硬件设备的需求包括机型、外设、接口、地点、分布、湿度、磁场干扰等：对软件的需求包括操作系统、网络、数据库等。

    • (5)界面需求

      • 考虑来自其他系统的输入，到其他系统的输出，对数据格式的特殊规定，对数据存储介质的规定。

    • (6)文档需求

      • 考虑需要哪些文档，文档针对哪些读者。

    • (7)数据需求

      • 考虑输入、输出数据的格式，接收、发送数据的频率，数据的准确性和精度，数据流量，数据需保持的时间。

    • (8)资源使用需求

      • 考虑软件运行时所需要的数据、其他软件、内存空间等资源：软件开发、维护所需的人力、支撑软件、开发设备等。

    • (9)安全保密要求

      • 考虑是否需要对访问系统或系统信息加以控制，隔离用户数据的方法，用户程序如何与其他程序和操作系统隔离以及系统备份要求等。

    • (10)可靠性要求

      • 考虑系统的可靠性要求，系统是否必须检测和隔离错误：出错后，重启系统允许的时间等。

    • (11)软件成本消耗与开发进度需求

      • 考虑开发是否有规定的时间表，软/硬件投资有无限制等。

    • (12)其他非功能性要求

      • 如采用某种开发模式，确定质量控制标准、里程碑和评审、验收标准、各种质量要求的优先级等，以及可维护性方面的要求。

• 系统设计

  在系统分析阶段，我们己经搞清楚了软件“做什么”的问题，并把这些需求通过规格说明书描述了出来，这也是目标系统的逻辑模型。进入设计阶段，要把软件“做什么”的逻辑模型转换成“怎么做”的物理模型，即着手实现软件系统的需求。
  系统设计的主要目的就是为系统制定蓝图，在各种技术和实施方法中权衡利弊，精心设计，合理地使用各种资源，最终勾画出新系统的详细设计方案。
  系统设计的主要内容包括新系统总体结构设计、代码设计、输出设计、输入设计、处理过程设计、数据存储设计、用户界面设计和安全控制设计等。
  目前，已存在的多种系统设计方法，常用的设计方法有以下两种。
  (1)面向数据流的结构化设计方法(SD)
  (2)面向对象的分析方法(OOD)
  系统设计的基本任务大体上可以分为概要设计和详细设计两个步骤。

  系统设计的结果是一系列的系统设计文件，这些文件是物理实现一个信息系统（包括硬件设备和编制软件程序）的重要基础。

  • 概要设计

    • 1)设计软件系统总体结构

      • 其基本任务是采用某种设计方法，将一个复杂的系统按功能划分成模块；确定每个模块的功能；确定模块之间的调用关系；确定模块之间的接口，即模块之间传递的信息；评价模块结构的质量。
      • 软件系统总体结构的设计是概要设计关键的一步，直接影响到下一个阶段详细设计与编码的工作。软件系统的质量及一些整体特性都在软件系统总体结构的设计中决定。

    • 2)数据结构及数据库设计

      • (1)数据结构的设计。逐步细化的方法也适用于数据结构的设计。在需求分析阶段，已经通过数据字典对数据的组成、操作约束和数据之间的关系等方面进行了描述，确定了数据的结构特性，在概要设计阶段要加以细化，详细设计阶段则规定具体的实现细节。在概要设计阶段，宜使用抽象的数据类型。

      • (2)数据库的设计。数据库的设计是指数据存储文件的设计，主要进行以下几方面设计。

        • ①概念设计。在数据分析的基础上，采用自底向上的方法从用户角度进行视图设计，一般用E-R模型来表述数据模型。ER模型既是设计数据库的基础，也是设计数据结构的基础。
        • ②逻辑设计。E-R模型是独立于数据库管理系统(DBMS)的，要结合具体的DBMS特征来建立数据库的逻辑结构。
        • ③物理设计。对于不同的DBMS,物理环境不同，提供的存储结构与存取方法各不相同。
          物理设计就是设计数据模式的一些物理细节，如数据项存储要求、存取方法和索引的建立等。

    • 3)编写概要设计文档

      • 文档主要有概要设计说明书、数据库设计说明书、用户手册以及修订测试计划。

  • 详细设计

    • (1)对每个模块进行详细的算法设计，用某种图形、表格和语言等工具将每个模块处理过程的详细算法描述出来。

    • (2)对模块内的数据结构进行设计。

    • (3)对数据库进行物理设计，即确定数据库的物理结构。

    • (4)其他设计

      • 根据软件系统的类型，还可能要进行以下设计。

        • ①代码设计。为了提高数据的输入、分类、存储和检索等操作，节约内存空间，对数据库中某些数据项的值要进行代码设计。
        • ②输入输出格式设计
        • ③用户界面设计

    • (5)编写详细设计说明书

    • (6)评审

      • 对处理过程的算法和数据库的物理结构都要评审。