导图社区 软件详细设计
- 355
- 7
- 1
- 举报
软件详细设计
以下是一篇关于软件详细设计的思维导图，讲述了软件工程概述、软件过程、需求工程、系统流程图等，希望对你有所帮助！
编辑于2022-03-25 11:09:40- 软件设计
- 相似推荐
- 大纲
软件详细设计
1.软件工程概述
专业化软件开发
软件工程是一门覆盖软件生产的各个方面的工程学科。
软件不仅是程序，还包括系统用户、质量保证人员以及开发者所需要的所有电子文档。软件产品的基本属性是可维护性、可依赖性、信息安全性、效率以及可接受性。
软件过程包括软件开发过程中所涉及的所有活动。软件规格说明、开发、确认和维护这些活动是所有软件过程的一部分。
世界上存在着很多不同类型的系统。每一种类型的系统的开发都需要一种与之相适应的软件工程工具和技术。几乎不存在适用于所有类型的系统的软件设计和实现技术。
软件工程基本思想适用于所有的软件系统。包括受管理的软件过程、软件可依赖性和信息安全性、需求工程和软件复用。
软件工程师对软件工程行业和整个社会负有责任，不应该只关心技术问题，而应该对影响他们工作的道德问题有所知晓。
2.软件过程
目标
目标：介绍软件过程（软件生产的一组相互连贯活动）思想。 理解软件过程和软件过程模型的概念； 了解3个通用的软件过程模型以及它们的适用情形； 了解需求工程、开发、测试和演化等基本软件过程活动； 理解软件过程有效地组织以应对软件需求和设计上的变化； 理解软件过程改进的思想以及影响软件过程质量的因素。
模型
瀑布模型
增量式开发
集成和配置
设计与实现
软件开发的实现阶段是开发一个可执行的系统以交付给客户的过程。 是对要实现的软件结构、数据模型和结构、系统构件间的接口描述，还会包括所用的算法。 分阶段完成。在设计过程中要不断添加所需的细节，同时不断修改先前设计方案。
设计过程的输入、过程活动以及过程的输出。设计的修改是不可避免的。
多数软件都会与其他软件系统交互。包括操作系统、数据库、中间件和其他应用系统。这些构成“软件平台”，即软件将会在其中运行的环境。
该平台的信息对于设计过程是一种重要的输入，因为设计者必须决定如何以最好的方式将系统与其环境集成在一起。
不同开发项目中设计过程活动有所相同，取决于所开发的系统类型。如，实时系统不包含数据库，没有数据库设计阶段
信息系统设计过程中可能包含的4个活动。 体系结构设计。 数据库设计 接口设计 构件选取和设计
设计过程输出是详细设计文档，设定精确和准确的系统描述。
软件确认
软件确认，或更一般性地，验证和确认，目的是确定系统是否符合它的规格说明，同时是否符合系统客户的期望。
程序测试，即用模拟测试数据运行系统，是最基本确认技术
确认还可以在从用户需求定义到程序开发的每一个软件过程阶段中包含检査性的过程（例如审査和评审）。
大部分验证和确认的时间和工作都是花在程序测试上。
测试过程包括以下这些阶段。 构件测试由系统的开发人员对组成系统的构件进行测试。 系统测试系统构件被集成到一起创建一个完整的系统。 客户测试。这是系统被接受并投入运行之前的测试过程中的最后阶段。
使用计划驱动的软件过程，测试是由一组测试计划驱动的。
独立的测试团队在基于系统规格说明和设计开发的测试计划基础上开展工作。
当一个系统要作为一个软件产品在市场上销售时，称为β测试。 β测试向一些同意使用目标系统的潜在客户交付该系统。 他们向系统开发者报告问题。
软件维护
软件的灵活性是大型、复杂系统中包含越来越多的软件的主要原因之一。
软件可以在系统开发之中或之后的任何时间进行修改。即使非常大范围的修改也比对于系统硬件的相应变更便宜很多。
软件开发过程和软件维护过程之间总是分离的。
开发和维护之间的区分越来越不合时宜。
现在很少有软件系统是全新的系统，将开发和维护视为一个连续的过程无疑是更合理的。 一种更加现实的认知是将软件工程视为一个演化式的过程，其中软件在其生命周期中随着不断变化的需求和客户需要而持续发生变化。
应对变化
大型软件项目变化都无法避免。系统需求随业务应对外部压力、竞争和管理优先级的需要等变化而发生变化。 变化增加软件开发成本，变化意味着已完工作须重做--返工。 两个相关的方法可降低返工本。 1.变化预测。软件过程含返工前预见或预测可能变化的活动。 2.变化容忍。通过过程和软件设计使得修改很容易进行。 两种应对变化以及修改系统需求的方法。 1.系统原型。系统或系统的一部分的一个版本被快速开发以检验客户需求及设计决策的可行性。是一种变化预测方法. 2.增量交付。系统增量被交付给客户进行评论和试验。这方法既支持变化避免又支持变化容忍。 重构的概念，即改进程序的结构和组织，一种容忍的机制。
原型
原型是一种软件系统的早期版本，用于演示概念、尝试候选设计方案、更好地理解问题以及可能的解决方案。 快速、迭代化的原型开发十分重要，可以控制成本.而系统相关利益相关者也可以在软件过程的早期试用系统原型。 软件原型可帮助对可能需要的变化进行预测： 1.需求工程过程中，原型可帮助对系统需求进行抽取和确认。 2.设计过程中，原型可探索软件解决方案、用户界面开发 原型可在系统设计中进行试验，以便检查所提设计的可行性。
增量式交付
一部分被开发的增量会交付给客户并在他们的工作环境中进行部署和使用。在增量式交付过程中，客户定义哪些服务对他们最重要，哪些最不重要。在此基础上定义一系列交付增量，每个增量提供系统功能的一个子集。如何将服务分配到各个增量中取决于服务的优先级，其中优先级最高的服务首先被实现和交付。
增量式交付有下面这些优势。 1.客户可将早期增量作为原型使用，获得后续增量的需求经验。增量是真实系统一部分，完成时用户不需重新学习。 2.客户不用等到整个系统交付就能从系统中获得价值。第一个增量可以满足他们最关键的需求，可以马上使用。 3.变更可以相对容易地加入到系统中。 4.优先权最高的服务最先交付，测试最充分。不大可能失效。 增量式交付也存在一些问题。 1.当新系统替换，迭代化交付。用户需要旧系统所有功能，不愿用一不完整的新系统试验。新旧同时使用不现实。 2.增量实现前，需求没有详细定义，确定公共基础设施很难。 3.迭代化过程的本质是规格说明与软件一起开发。釆购方式相冲突，系统规格说明是合约一部分。最后完成。
过程改进
两种方法实现过程改进和变更 1.过程成熟度方法，关注改进过程和项目管理，并将好的软件工程实践引入到组织中。 2.敏捷方法，关注迭代化的开发以及降低软件过程中的额外开销，主要特点是快速交付功能以及对客户需求变更快速响应。 过程成熟度方法，基于过程改进的一般过程的阶段如下 1.过程度量。对软件过程或产品的一个或多个属性进行度量。这些度量构成了一个基线，可以帮助确定过程改进是否有效。 2.过程分析，对当前过程进行评价，识别过程中的弱点和瓶颈。描述过程的过程模型（称为过程地图）在此阶段开发。 3.过程改变。对当前过程已识别出的过程弱点提出改变方法。引入变更后，改进循环继续收集与变化有效性相关的数据。
过程成熟度的思想是在20世纪80年代后期被提出的。当时，软件工程研究所（Software Engineering Institute，SEI）提出了他们的过程能力成熟度模型。
5个过程成熟度等级 1.初始级。与过程域相关的目标令人满意。对所有过程，将要进行的工作范围得到了明确定义并与团队成员进行了沟通。 2.受管理级。与过程域相关的目标得到满足，组织政策明确定义每个过程应当在何时使用。必须有文档化项目计划定义项目目标。资源管理和过程监控规程必须在整个机构中到位。 3.已定义级。关注组织的标准化以及过程的部署。每个项目都有一个受管理的过程，该过程是在一组定义好的组织过程基础上按照项目需求进行适应性调整得到的。必须收集过程资产和过程度量，并用于未来的过程改进。 4.量化管理级。存在相应的组织职责，使用统计或其他定量方法来控制子过程。即，所收集的过程和产品度量必须用于过程管理。 5.优化级。组织必须使用过程和产品度量来驱动过程改进必须对趋势进行分析，并根据不断变化的业务需要对过程进行调整。
需求工程
目标
目标介绍软件需求，解释在发现并文档化这些需求的过程中所涉及的过程。 理解用户和系统需求的概念，以及为什么这些需求应当以不同的方式进行描述； 理解功能和非功能性软件需求的区别； 理解主要的需求工程活动，包括抽取、分析、确认，以及这些活动之间的关系； 理解需求管理的必要性，以及需求管理如何支持其他需求工程活动。 对一个系统的需求是关于该系统应当提供的服务以及对其运行的约束的描述。 需求工程：找出、分析、文档化并检查这服务和约束的过程。
需求
用户需求：使用自然语言和图形，陈述系统被期望向系统用户提供什么服务以及系统运行必须满足的约束。用户需求可以是对系统特征的大概陈述，也可以是关于系统功能的洋细和精确的描述。 系统需求：对软件系统功能、服务和运行约束的更详细的描述；系统需求文档(功能规格说明)精确定义要实现哪些东西。是合同一部分。
向不同类型读者传达关于系统的信息需要不同类型的需求。 不同类型的读者会以不同的方式使用这些需求。
不同类型的文档读者都是系统利益相关者的例子。 从系统的最终用户、管理人员直到对系统的可接受性进行认证的外部监管者等外部利益相关者都可能是利益相关者。 Mentcare系统包括以下利益相关者。 病人以及家属；医生；护士；接待人员；IT人员；医疗伦理管理人员；医疗管理人员；医疗记录人员。 需求工程通常被认为是软件工程过程的第一个阶段。 在一个系统的采购或开发决策做出之前就开发出来。 建立关于系统要做什么以及系统可以提供的好处的高层视图。 这些需求接下来可以在可行性研究中进行考虑。 可行性研究结果帮助管理层决定是否继续该系统采购或开发。
功能性需求。是对系统应该提供的服务、系统应该如何响应特定的输入、系统在特定的情形中应该如何表现等的陈述。某些情况，功能性需求还可明确地陈述系统不应该做什么。 非功能性需求。这些需求是对系统提供的服务或功能的约束，包括时间性约束、对于开发过程的约束、标准规范中所施加的约束等。非功能性需求经常适用于系统整体而不是单个的系统特征或服务。 不同类型的需求之间的区别并不像这里的简单定义所表达的那样清楚。一个关注信息安全的用户需求，例如，一个关于授权用户访问权限，可能看起来像是一个非功能性需求。然而，当开发得更加详细之后，这个需求可能会产生其他一些明显是功能性需求的需求，例如，要求在系统中包含用户认证的功能。
功能性需求
描述系统应该做什么。 这些需求取决于所开发的软件的类型、软件所期望的用户，以及该组织在书写需求时通常所采取的方法。 当被表达为用户需求时，功能性需求应当用自然语言描述，以使得系统用户和管理人员能够理解它们。 功能性系统需求将用户需求展开，是面向系统开发者描述的，应该详细描述系统功能，系统的输入、输出和异常。 功能性系统需求可以是关于系统应该做什么的大体上的需求，也可以是反映局部的工作方式或者组织已有系统的非常特定的需求。
例如，用户应当能够搜索所有诊所的预约列表。 这需求背后的考虑是有心理健康问题的病人有时候思维混乱，他们可能在某诊所预约但实际上去了另外一家。如果他们有预约，那么将会被记录为已预约而不管是哪个诊所。 提出搜索需求的医护工作人员所期望的“搜索”可能是给定一个病人名字，系统在所有诊所的所有预约中查找这个名字。然而，这需求描述并不明确。开发者会按照最容易实现的方式理解。他们所理解的搜索功能可能需要用户选择一个诊所，然后搜索预约了这个诊所的病人。这需要更多的用户输入，因此需要花更长的时间来完成搜索。 理想情况下，一个系统的功能性需求规约应当是完整、一致的。完整性意味着用户所需要的所有的服务和信息都应该被定义；一致性意味着需求不应当自相矛盾。
非功能性需求
是指与系统向其用户提供的特定服务不直接相关的需求。 通常会刻画或约束系统的整体特性。 可能会与系统的涌现特性(如可靠性、响应时间、存储)相关。 或者，它们也可以定义对系统实现的约束。如，I／O能力。 非功能性需求经常比单个的功能性需求更关键。 确定哪些构件实现了非功能性需求困难。这些非功能性需求的实现经常跨越整个系统，因为以下两点原因： 非功能性需求可能影响系统整个体系结构而非单个构件。 一个非功能性需求，例如信息安全需求，可能会产生多个相互联系的功能性需求，这些功能性需求定义了实现该非功能性需求所需要的新的系统服务。 此外，非功能性需求还有可能产生对已有需求构成约束的新需求，例如，限制对系统中信息的访问。
实践中，系统的客户经常感觉很难将自己的目标表达为可度量的需求 非功能性需求常与其他功能性或非功能性需求冲突，如读卡器不能连PAD 在需求文档中很难将功能性和非功能性需求分开
可以用来刻画非功能性系统属性的度量指标，可以在系统测试时对这些特性进行度量以检查系统是否满足非功能性需求。
需求抽取
一个抽取和分析过程的过程模型如图所示 1．需求发现和理解：与系统利益相关者迸行交互以发现需求。来自利益相关者和文档的领域需求也在此活动中发现。 2．需求分类和组织。处理所收集的未整理需求，将相关的需求进行分组并将它们组织为内聚的聚类。 3．需求优先级排序和协商。该活动对需求进行优先级排序，找出并通过协商解决需求冲突。利益相关者必须一起协商以解决分歧并做出妥协、达成一致。 4．需求文档化。对需求进行文档 化并提供给下一轮螺旋。
需求抽取包含与不同类型的利益相关者交谈以发现关于待开发系统的信息。可以补充关于现有系统及其使用的知识，以及来自不同种类文档的信息。需要花时间理解人们如何工作、他们生产什么、他们如何使用其他系统，以及他们要如何变化以适应新系统。 需求抽取有两个基本的方法。 1．访谈，开发者和其他人谈论他们做的事情。 2．观察或人种学调查，观察人们做自己的工作来了解他们使用哪些制品、他们如何使用这些制品等。 人种学调查是一种观察技术，可以用来理解运行过程，并且帮助得出支持这些过程的软件需求。
需求规格说明
需求规格说明是在需求文档中撰写用户和系统需求的过程：理想情况下，用户和系统需求应当是清晰、无二义、易于理解、完整和一致的。
表示法 描述 自然语言句子 使用数字编号的自然语言句子来书写需求。每个句子应当表达一条需求 结构化自然语言 基于一个标准的表格或摸板用自然语言书写需求，每个字段提供关于需求的一个方面的信息 图形化表示法 定义系统的功能性需求，辅以文本注释的图形化模型。统一建模语言(UML)用例和顺序图被广泛使用 数学规格说明 这些表示法基于有限状态机或集合等数学概念。虽然这些无二义的规格说明可以减少需求文档中的二义性，但是大多数客户不理解形式化的规格说明，他们无法检查其是否表达了他们的想法，因此不愿意将其作为系统合约接受。
用户需求应当描述功能性需求和非功能性需求，以使不具有详细的技术知识的系统用户也可以理解。 应当只刻画系统的外部行为。需求文档不应该包含系统体系结构或设计的细节。 不应该使用软件术语、结构化表示法或者形式化表示法。 应该用自然语言书写用户需求，带有简单的表格、表单和直观的图形。 系统需求是用户需求的详述版本，软件工程师将其用作系统设计的起始点。 系统需求增加了细节并解释了系统应当如何提供用户需求。 它们可以作为系统实现的合约的一部分 系统需求应当是对整个系统的完整以及详细的规格说明。
自然语言规格说明
自然语言表达能力强、直观、具有普适性。 也具有潜在的模糊性和二义性，解读取决于读者的背景。 书写自然语言需求时尽量减少误解，遵循指南： 1.使用标准格式并确保所有需求定义遵循。使遗漏不太会发生，同时需求更易检查。尽量用一两句话自然语言书写需求。 2.一致方式使用语言，区分必须满足和期望满足的需求。必须满足是系统必须支持的需求，用“必须”( shall)表达。期望满足不是必不可少的，用“应该”( should)来表达。 3.强调性文本（粗体、斜体或颜色）突出需求中的关键部分。 4.不要假设读者理解技术性语言。“体系结构”和“模块” 容易被误解。尽量避免专业术语、缩写和首字母缩略词。 5.有可能，都应当尽量将每个用户需求与其原理关联起来。 原理应解释为什么需求被包含及谁提出的需求（来源），在需求要变化时咨询谁。需求原理在需求发生变化时尤其有用，因为它可以帮助判断哪些变化是不适宜的。
下面描述这些指南该如何使用 3.2系统必须每10分钟测量一次血糖，如需要就供应一次胰岛素。(血糖变化相对比较慢，因此不需要更频繁的测量；测量间隔时间过长的话会导致不必要的高血糖水平。) 3.6系统必须每分钟运行一次例行的自检，测试表l定义的条件，并执行表l中所定义的相关动作。(例行的自检可以发现硬件和软件问题并警告用户常规操作可能有问题。)
结构化规格说明
结构化自然语言使用标准的方式而非自由文本方式书写需求 保持自然语言的表达能力和可理解性，同时保证一定统一性 结构化语言表示法使用模板来刻画系统需求。 可使用编程语言元素来表示可选项和迭代，可强调关键元素。 推荐先在卡片上书写用户需求，每张卡片一条需求。他们建议每张卡片上包含一些字段，如需求原理、与其他需求的依赖关系、需求来源、支持性的材料等。 需要定义一个或多个标准的需求模板，并将这些模板表示为结构化的表单。 规格说明可以围绕系统操纵的对象、系统执行的功能或者系统处理的事件进行组织。
当使用一种标准格式来刻画功能性需求时，应包含以下信息。 1.对所刻画的功能或实体的描述； 2.关于其输入以及输入来源的描述； 3.关于其输出以及输出目的地的描述； 4.关于计算所需的信息或者所需要的系统中其他实体的信息（“要求”部分）； 5.关于所要采取的行动的描述； 6.如果使用一个功能性的方法，那么用一个前置条件明确该功能调用前必须满足的条件，用一个后置条件刻画该功能调用后必须满足的条件； 7.关于该操作的副作用（如果有的话）的描述。
结构化可以去除自然语言规格说明中的一些问题。 规格说明中的可变性减少了，需求可以更有效地组织。 一种清晰、无二义很难，特别是刻画的计算很复杂。 解决问题，可以向自然语言需求中增加额外的信息，如，通过使用表格或系统的图形化模型。 这些可以显示计算是如何进行，系统状态如何变化，用户如何与系统交互，以及动作序列如何执行。
用例
用例是图形化模型和结构化文本描述用户与系统间交互的方式 最简单用例形式，一个用例识别参与一个交互的参与者，并且对交互的类型进行命名。 在此基础上，可以添加一些描述与系统交互的附加信息。 这些附加信息可以是一段文本描述，或者是一个或多个图形化模型，例如UML顺序图或状态图。 用例的简要描述可以如下。 安排会诊允许两个或更多不同科室的医生来同时查看同一个病人的记录。一个医生通过从当前在线的医生的下拉菜单中选择参与人来发起会诊。病人记录显示在他们的屏幕上，但只有发起的医生可以编辑记录。此外，系统会创建一个文本聊天窗口来帮助进行相关行动的协调．这里的一个假设是，可以另外安排一个电话语音交流。
软件需求文档
也称为软件需求规格说明( Software Requirement Specification，SRS)，是关于系统开发者应当实现的所有东西的正式陈述。 可以同时包括一个用户需求及对于系统需求的详细规格说明。 有时用户和系统需求被集成到同一个描述中。而有时，用户需求在系统需求规格说明的一个引言章节中描述。 外包开发，不同团队开发系统不同部分，以及当详细的需求分析是必需的时候，需求文档十分关键。 其他情况，如开发软件产品或业务系统，不一定是必需的。 敏捷方法不使用正式文档，经常增量地收集用户需求并且将它们作为简短的用户故事写在卡片或白板上。优先级排序。 需求文档有多种用户，从高层管理人员到软件工程师。 文档包含的详细程度取决于系统类型以及所使用的开发过程。
需求确认
需求确认是检查需求是否定义了客户真正想要的系统的过程。 需求确认非常重要，因为如果需求文档中的错误在开发过程中或在系统投入服务后被发现，则会导致广泛的返工开销。 通过进行系统变更修正一个需求问题的开销通常比修复设计或编码错误要高得多。一个需求变更通常意味着系统设计和实现也必须修改。而且，系统接下来还必须重新测试。
需求确认过程中，对需求文档中需求进行不同类型的检查。 1.正确性检查。检查需求是否反映了系统用户的真实需要。 环境不断变化，用户需求可能在最初被抽取后已发生变化。 2.一致性检查。文档中的需求不应该冲突。不应该有相互矛盾的约束或者对同一个系统功能的不同描述。 3.完整性检查。需求应当定义系统用户想要的所有功能及约束。 4.现实性检查。使用现有技术的知识，对需求进行检查以确保可以在预算范围内实现。考虑系统开发预算和进度。 5.可验证性检查。为了减少客户和承包商之间可能的争议，所描述的系统需求应当总是可验证的。 意味着应当能够针对每一条所刻画的需求编写一组测试，以便显示所交付的系统满足该需求。
需求确认技术 1.需求评审。由一个评审团队系统性地分析需求，检查错误和不一致性。 2.原型化。开发一个可执行的系统模型，并与最终用户和客户一起使用该模型，来确认是否满足他们的需要和期望。利益相关者对系统进行诚验，并向开发团队反馈需求变更。 3.测试用例生成。需求应该是可测试的。如果作为确认过程的一部分，设计针对一个需求的测试，那么经常可以揭示需求中的问题。 写代码之前，根据用户需求开发测试是测试驱动开发的一个重要组成部分。 不应当低估需求确认中所包含的问题。
大型软件系统需求总是在变化中。这样的频繁变化的一个原因是，这些系统经常被开发用于应对“非常规”的问题——无法完备定义的问题。 因为问题无法被充分定义，软件需求不可避免地会不完整：在软件开发过程中，利益相关者对于问题的理解在不断变化，于是，系统需求必须演化以反映对这一变化的问题的理解。 一旦一个系统已经安装并被正常使用，新的需求不可避免地会出现。 部分原因是原始需求中存在需要纠正的错误和遗漏。然而，大部分对系统需求的变更是由于系统的业务环境发生变化而产生的。
需求变更
相关者的支持的平衡必须变化，而需求优先级要进行调整。1.系统业务和技术环境总是会在系统安装后发生变化。可能引入新的硬件，或者更新已有的硬件；系统可能要与其他系统建立接口；业务优先级可能发生变化（所需要的系统支持会因此发生变化）；新的法律和监管要求可能会出现并要求系统满足。 2.为系统付钱的人和系统的用户经常是不同的人。系统客户由于组织和预算约束而提出需求，这些可能与最终用户的需求相互冲突，并且在交付后可能必须为用户增加新特征。 3.大型系统通常有各种各样的利益相关者群体，他们优先级可能相互冲突或矛盾。最终的系统需求不可避免地要进行折中，而有些利益相关者必须给予较高的优先级。根据经验，经常会发现对于给予不同利益
系统流程图
符号
利用符号可以把一个广义的输入输出操作具体化为读写存储在特殊设备上的文件（或数据库），把抽象处理具体化为特定的程序或手工操作等。
分层
面对复杂的系统时，好的方法是分层次地描绘。首先用一张高层次的系统流程图描绘系统总体概貌，表明系统关键功能。然后分别把每个关键功能扩展到适当详细程度，画在单独一页纸上。 分层次的描绘方法便于阅读者按从抽象到具体的过程逐步深入地了解一个复杂的系统。
数据流图
画数据流图的基本目的是利用它作为交流信息的工具。 数据流图的另一个主要用途是作为分析和设计的工具。 数据流图辅助物理系统的设计时，以图中不同处理的定时要求为指南，能够在数据流图上画出许多组自动化边界，每组自动化边界可能意味着一个不同的物理系统
数据字典
内容
数据字典应该由对下列4类元素的定义组成。 数据流 数据存储 处理 数据流分量 记录数据元素下列信息： 一般信息(名字，别名，描述等)，定义(数据类型，长度，结构等)，使用特点(值的范围，使用频率，使用方式——输入、输出、本地，条件值等)，控制信息(来源，用户，使用它的程序，改变权，使用权等)和分组信息(父结构，从属结构，物理位置——记录、文件和数据库等)。
数据元素的别名就是该元素的其他等价的名字，出现别名主要有下述3个原因： 对于同样的数据，不同的用户使用了不同的名字。 一个分析员在不同时期对同一个数据使用了不同的名字。 两个分析员分别分析同一个数据流时，使用了不同的名字
定义数据版本
由数据元素组成数据的方式只有下述3种基本类型： 顺序即以确定次序连接两个或多个分量。 选择即从两个或多个可能的元素中选取一个。 重复即把指定的分量重复零次或多次。 第4种关系算符 =意思是等价于(或定义为)； +意思是和(即连接两个分量)； ［］意思是或(即从方括弧内列出的若干个分量中选择一个)，通常用“|”号隔开供选择的分量； {}意思是重复(即重复花括弧内的分量)； ()意思是可选(即圆括弧里的分量可有可无)。
由数据元素组成数据的方式只有下述3种基本类型： 顺序即以确定次序连接两个或多个分量。 选择即从两个或多个可能的元素中选取一个。 重复即把指定的分量重复零次或多次。 第4种关系算符 =意思是等价于(或定义为)； +意思是和(即连接两个分量)； ［］意思是或(即从方括弧内列出的若干个分量中选择一个)，通常用“|”号隔开供选择的分量； {}意思是重复(即重复花括弧内的分量)； ()意思是可选(即圆括弧里的分量可有可无)。
数据字典最重要的用途是作为分析阶段的工具 数据字典中包含的每个数据元素的控制信息是很有价值的 数据字典是开发数据库的第一步，而且是很有价值的一步
实现
目前，数据字典几乎总是作为 CASE“结构化分析与设计工具”的一部分实现的。在开发大型软件系统的过程中，数据字典的规模和复杂程度迅速增加，人工维护数据字典几乎是不可能的。 开发小型软件系统时暂时没有数据字典处理程序，建议用卡片形式书写数据字典，每张卡片上保存描述一个数据信息。 例子：几个数据元素的数据字典卡片，以具体说明数据字典卡片中上述几项内容的含义。