免费智能真题库 > 历年试卷 > 软件设计师 > 2020年下半年 软件设计师 下午试卷 案例
  第2题      
  知识点:   概念模式   管理需求   来源   需求分析

 
M集团拥有多个分公司,为了方便集团公司对各个分公司职员进行有效管理,集团公司决定构建一个信息平台以满足公司各项业务管理需求
需求分析
1、分公司关系模式需要记录的信息包括公司编号、名称、经理号、可联系地址和电话。分公司编号唯一标记分公司关系模式中的每一个元组,每个分公司各有一名经理,负责分公司的管理工作,每个分公司设立仅为本分公司服务的多个业务部,业务部包括:研发部、财务部、采购部、交易部等。
2、业务部关系模式需要记录的信息包括业务部的编号、名称、地址、电话和分公司编号,业务部编号唯一标记分公司关系模式中的每一个元素,每个业务部各有一名主管负责业务部的管理工作,每个业务部有多名职员,每个职员只能来源于一个业务部。
3、职员关系模式需要记录的信息包括职员号、姓名、所属业务部编号、岗位、电话、家庭成员姓名和成员关系。其中职员号唯一标记职员关系,岗位包括:经理、主管、研发员、业务员等。
【关系模式】
分公司(分公司编号、名称、(a)、 联系地址 )
业务部(业务部编号、名称、(b)、 电话)
职员(职员号、姓名、岗位、(c)、 电话、家庭成员姓名、关系)
概念模式设计】

 
问题:2.1   根据问题描述,补充4个联系,完善图2-1的实体联系图,联系名可用联系1、联系2、联系3和联系4代替 ,联系的类型为1 : 1、1 : n和m: n(或1 : 1、1: *和*:*)
 
问题:2.2   根据题意将以上关系模式中的空(a) ~ (c)的属性补充完整,并填入对应位置。
 
问题:2.3   (1)分析分公司关系模式的主建和外键
(2)分析业务部关系模式的主建和外键
 
问题:2.4   在职员关系模式中,假设每个职员有多名家庭成员,那么职员关系模式存在什么问题?应如何解决?
 
 
 

   知识点讲解    
   · 概念模式    · 管理需求    · 来源    · 需求分析
 
       概念模式
        概念模式也称模式,是数据库中全部数据的逻辑结构和特征的描述,它由若干个概念记录类型组成,只涉及型的描述,不涉及具体的值。概念模式的一个具体值称为模式的一个实例,同一个模式可以有很多实例。概念模式反映的是数据库的结构及其联系,所以是相对稳定的;而实例反映的是数据库某一时刻的状态,所以是相对变动的。
        需要说明的是,概念模式不仅要描述概念记录类型,还要描述记录间的联系、操作、数据的完整性和安全性等要求。但是,概念模式不涉及存储结构、访问技术等细节。只有这样,概念模式才算做到了“物理数据独立性”。
        描述概念模式的数据定义语言称为“模式DDL(Schema Data Definition Language)”。
 
       管理需求
        从用户的角度来讲,一个网络管理系统应该满足以下要求。
        ◆同时支持网络监视和控制两方面的能力。
        ◆能够管理所有的网络协议。
        ◆尽可能大的管理范围。
        ◆尽可能小的系统开销。
        ◆可以管理不同厂家的联网设备。
        ◆容纳不同的网络管理系统。
        ◆网络管理的标准化。
        在OSI网络管理框架模型中,基本的网络管理功能被分为5个功能域:配置管理(Configuration Management)、性能管理(Performance Management)、故障管理(Fault Management)、安全管理(Security Management)和计费管理(Accounting Management)。
        网络管理的标准化产品包括ISO的CMIS/CMIP(Common Management Information Service/Common Management Information Protocol)、Internet体系结构委员会(Internet Architecture Board, IAB)的SNMP和管理信息库(MIB),这些内容将在第5章详细介绍。
 
       来源
        (1)由信息技术支持工程师提供。召集有经验的信息技术支持工程师,要求他们提供知识库的内容,知识库的建立并不是某个人智慧的积累,毕竟一个人的知识和经验有限,我们需要在企业中营造这样一种乐意共享自身知识的氛围,能够提供有效知识条目的工程师能够获得奖励。发布一系列奖惩和鼓励措施。
        (2)从过往的事件和问题的处理日志中提炼。事件与问题的处理过程需要详细记录,能为下一次处理相同事件提供指导和参考。知识库内容可以从这些处理日志中提炼后获得,事件处理步骤的详细记录对于知识库内容的建立有着重要的帮助。
 
       需求分析
        需求分析的方法种类繁多,不过如果按照分解的方式不同,可以很容易地划分出几种大类型:
        (1)结构化分析方法。本节后续内容将详细讨论SA的内容。
        (2)面向对象分析方法。将在10.3节中进行详细介绍。
        (3)面向问题域的分析(Problem Domain Oriented Analysis, PDOA)方法。PDOA更多地强调描述,而少强调建模。它的描述大致分为关注问题域和关注解系统的待求行为这两个方面。问题框架是PDOA的核心元素,是将问题域建模成为一系列相互关联的子域。也可以把问题框架看作是开发上下文图,但不同的是上下文图的建模对象是针对解系统,而问题框架则是针对问题域。也就是说,问题框架的目标就是大量地捕获更多有关问题域的信息。PDOA方法现在还在研究阶段,并未广泛应用。
               业务流程分析
               业务流程分析的目的是了解各个业务流程的过程,明确各个部门之间的业务关系和每个业务处理的意义,为业务流程的合理化改造提供建议,为系统的数据流程变化提供依据。
               业务流程分析的步骤如下:
               (1)通过调查掌握基本情况。
               (2)描述现有业务流程(绘制业务流程图)。
               (3)确认现有业务流程。
               (4)对业务流程进行分析。
               (5)发现问题,提出解决方案。
               (6)提出优化后的业务流程。
               在业务流程图中使用的基本符号如下图所示。
               数据流图
               DFD是结构化分析中的重要方法和工具,是表达系统内数据的流动并通过数据流描述系统功能的一种方法。DFD还可被认为是一个系统模型,在信息系统开发中,一般将它作为需求说明书的组成部分。
               
               业务流程图符号
               DFD从数据传递和加工的角度,利用图形符号通过逐层细分地描述系统内各个部件的功能和数据在它们之间传递的情况,来说明系统所完成的功能。具体来说,DFD的主要作用如下:
               (1)DFD是理解和表达用户需求的工具,是系统分析的手段。由于DFD简明易懂,理解它不需要任何计算机专业知识,因此通过它同客户交流很方便。
               (2)DFD概括地描述了系统的内部逻辑过程,是系统分析结果的表达工具,因而也是系统设计的重要参考资料,是系统设计的起点。
               (3)DFD作为一个存档的文字材料,是进一步修改和充实开发计划的依据。
               在DFD中,通常会出现4种基本符号,分别是数据流、加工、数据存储和外部实体(数据源及数据终点)。数据流是具有名字和流向的数据,在DFD中用标有名字的箭头表示。加工是对数据流的变换,一般用圆圈表示。数据存储是可访问的存储信息,一般用直线段表示。外部实体是位于被建模的系统之外的信息生产者或消费者,是不能由计算机处理的成分,它们分别表明数据处理过程的数据来源及数据去向,用标有名字的方框表示。下图是一个典型的DFD示例。
               
               办理取款手续的DFD
               为了表达数据处理过程中的数据加工情况,用一个DFD是不够的。稍微复杂的实际问题,在DFD中常常出现十几个甚至几十个加工。这样的DFD看起来很不清楚。层次结构的DFD能很好地解决这一问题。按照系统的层次结构进行逐步分解,并以分层的DFD反映这种结构关系,能清楚地表达整个系统。
               下图给出分层DFD的示例。数据处理S包括3个子系统1、2、3。顶层下面的第一层DFD为DFD/L1,第二层的DFD/L2.1、DFD/L2.2及DFD/L2.3分别是子系统1、2和3的细化。对任何一层数据流图来说,它的上层图称为父图,在它下一层的图则称为子图。
               
               分层数据流图
               概括地说,画DFD的基本步骤,就是“自顶向下,逐层分解”。检查和修改的原则如下:
               (1)DFD中的所有图形符号只限于前述4种基本图形元素。
               (2)顶层DFD必须包括前述4种基本元素,缺一不可。
               (3)顶层DFD中的数据流必须封闭在外部实体之间。
               (4)每个加工至少有一个输入数据流和一个输出数据流。
               (5)在DFD中,需按层给加工框编号。编号表明了该加工处在哪一层,以及上下层的父图与子图的对应关系。
               (6)规定任何一个数据流子图必须与它上一层的一个加工对应,两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。
               (7)可以在DFD中加入物质流,帮助用户理解DFD。
               (8)图上每个元素都必须有名字。
               (9)DFD中不可夹带控制流。
               数据字典
               数据字典是关于数据的信息的集合,也就是对DFD中包含的所有元素的定义的集合。DFD和数据字典共同构成系统的逻辑模型。没有DFD,数据字典难以发挥作用;没有数据字典,DFD就不严格。只有把DFD和对DFD中每个元素的精确定义放在一起,才能共同构成系统的规格说明。
               数据字典的设计包括:数据流设计、数据元素字典设计、数据处理字典设计、数据结构字典设计和数据存储设计。这些设计涵盖了数据的采集和范围的确定等信息。在数据字典的每一个词条中应包含以下信息:名称、别名或编号、分类、描述、何处使用。
               对加工的描述是数据字典的组成内容之一,常用的加工描述方法有结构化语言、判定树及判定表。
               (1)结构化语言:介于自然语言和形式语言之间的一种半形式语言,在自然语言基础之上加了一些限度,使用有限的词汇和有限的语句来描述加工逻辑。结构化语言是受结构化程序设计思想启发而扩展出来的。结构化程序设计只允许3种基本结构。结构化语言也只允许3种基本语句,即简单的祈使语句、判断语句和循环语句。与程序设计语言的差别在于结构化语言没有严格的语法规定,与自然语言的不同在于它只有极其有限的词汇和语句。结构化语言使用3类词汇:祈使句中的动词、数据字典中定义的名词及某些逻辑表达式中的保留字。
               (2)判定树:若一个动作的执行不只依赖一个条件,而与多个条件有关,那么这项策略的表达就比较复杂。如果用结构化语言的判断语句,就有多重嵌套,层次一多,可读性就会下降。用判定树来表示,可以更直观一些。
               (3)判定表:一些条件较多、在每个条件下取值也较多的判定问题,可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系,判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑,是在某种条件取值组合情况下可能的结果,它不能表达加工的顺序,也不能表达循环结构,因此判定表不能成为一种通用的设计工具。
   题号导航      2020年下半年 软件设计师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
 
第2题    在手机中做本题