软考全攻略--下午题必过秘籍



        软考已经过去两天了，现在再发些有关软考技巧的文章有点晚了，但在准备时总结的一些技巧还是不想就这么被时间冲洗干净，经过考试的见证这些做题技巧在考试时发挥了很大的作用，同时也希望这些做题技巧能够帮助将要考的童鞋。

一、数据流图

    1、常考类型

      （1）按照描述填写实体
                实体类型：与系统进行交互的外部事物，在做题时注意找出描述中有关事物的名词。
      （2）填写顶层流图的文件和补充流图

    2、涉及知识点

         (1) 数据平衡原则
　　    ① 在分层数据流图中，父图和子图要平衡，也就是说，父图中某加工的输入输出数据流必须与它的子图的输入输出数据流在数量和名字上相同。
　　    ②数据平衡的另一个方面是说：每个加工必须即有输入数据流又有输出数据流，而且一个加工所有输出数据流中的数据必须能从该加工的输入数据流中直接获得，或者是通过该加工能产生的数据。
         (2) 要特别注意的几个细节问题
　　    ① 除了流向数据存储(文件)或从数据存储流出的数据流不必命名外，其它每个数据流都必须有一个合适的名字。
　　    ②流向文件的数据流，表示写入数据，流出文件的数据流表示读文件。在整套数据流图中，每个文件必须既有读的数据流又有写的数据流，但在某一张子图中可能只有读没有写，或者只有写没有读。
　　    ③在逐步精化的过程中，若一个文件首次出现时只与一个加工有关，既该文件是个加工的内部文件，那么该文件在当层图中不必画出，可在该加工的细化图中画出。

   3、解题的技巧

　　(1)阅读题干的技巧。快速的阅读第一遍，基本了解题目所涉及到的知识点或者事务，打记实体对象和存储文件，甚至可以将数据流也标记一下;这一步重点落在问题上，一般问题不难，但一定要看清问题。带着问题来看第二遍，边看边解决。

　　(2)要有整体的概念，不能因一个点符合就断定是它，尤其是数据对象。

　　(3)注意解题的速度，一般在20分钟以内为最好。

　　(4)解题的过程中，每一条数据流都能够在[说明]中找到相应的语句。

　　(5)数据流名称要写对，每错一个字扣0.5分;流向也要写对。

　　(6)做好以后，复查一遍;不要边做边怀疑、边修改，那样会担误时间，且错误更多。

二、数据库设计    

    1、常考类型

        （1）给出不完整的ER模型补充关系和多重度。
        （2） ER模型转成关系模型，填写属性并指明主外键
           

    2、做题技巧

        （1）模型转化原则

            1：1，转换成一个独立的关系模型时，各端实体的码作为关系的属性，关系的主键可以是各实体的任意主键。合并要加入另一个实体的主键作为外键。
            1：n，独立的，关系的码是n端实体的码，各实体的码作为关系的属性。
            m：n，独立的，关系的码为各端实体的组合，
            m：n：p，独立的，各端实体码的组合是关系的主键。  

        （2）确定主外键

            确定主键：确定主键的时候按照题中描述的、给出的主关键字，往往会有唯一确定一元组之类的词，不能确定的按照上面说的几条原则确定。
            确定外键：明确外键的定义，两个关系模式共享同一属性，且属性是其中一个关系模式的主键，则它一定是另外一个关系模式的外键。
            外键：两个关系表有公共的属性，并且在其中一个表中的公共属性是主键，则在另一个表中该属性肯定是外键。

   符合三范式，避免出现数据冗余，同一个属性应包含在尽可能少的关系中，不能出现属性冲突。

三、UML模型

    1、用例图

        在UML中，用例之间有3种关系：包含（indude）、概括（generalize）和扩展（extend）。
        包含：使用《include》关键字，图形是虚线箭头，箭头指向小用例。强调包含关系，一个用例在执行时一定会执行另一个用例。如果多个用例中都含有相同的事件流，那么可以将其抽取出来放在一个单独的用例中，其他用例都可以通过包含（include）这个用例来使用其中的事件流。包含关系可以避免在多个用例的描述中重复拷贝相同的事件流。
        概括：图形和集成的图形相同，三角箭头指向父用例。概括关系是指子用例（child use case）继承父用例（parent use case）的行为，而子用例本身还可以增加新的行为或重置父类的某些行为。这种关系与面向对象程序设计中的“继承”很类似。
        扩展：使用《extend》关键字，图形是一个虚线箭头，箭头执行被扩展的用例。一个用例扩展了另一个用例的功能，强调可能关系，在执行被扩展的用例时，扩展的用例可能执行也可能不执行。扩展关系与概括关系有相似之处，但是比概括关系更为严格。基础用例必须声明特定的扩展点，而扩展用例只能在这些扩展点上添加新行为。

    2、类图

        查找类图及填写之间的多重度。查找多重度时要根据题中给出的信息确定，题中的说明往往在描述的时候就确定了类和类之间的多重性。

四、算法

    1、算法特征

          有穷性：执行有限次循环后完成，结束
          确定性：每条语句有确切含义，不会有歧义出现。唯一的一条执行路径，同样的输入对应同样的输出
          可行性：算法能够得出结果，
          输入：一个算法有零个或多个输入
          输出：一个算法有一个或多个输出

    2、分析基础

          时间复杂度：算法执行的次数，一般指代循环执行的次数，嵌套循环次数相乘，统计循环相加。
          空间复杂度：算法执行过程中另外申请的内存空间个数。

    3、基本算法

• 分治法
  • 递归法
  • 把大问题粉制成小问题，分而治之
  • 子问题独立与原问题相同
  • 步骤
    • 分解/求解/合并
  • 典型例题：归并排序
• 动态规划
  • 分解子问题，先求子问题的解，最后从子问题中得到原问题的解
  • 分解的子问题不相互独立
  • 常用于求解最优性质的问题
  • 典型实例
    • 背包/最长公共子序列
• 贪心
  • 根据已有信息做选择，贪心发不是从整体考虑，某种意义上的局部最优
  • 问题类型
    • 最优子结构
    • 贪心选择
• 回溯法
  • 通用的解题法
  • 深度优先的方式系统的搜索问题的解
  • 可以系统搜索一个问题的所有解或任一解
  • 适于解决一些组合较大的问题
• 迭代法
  • 用于求解方程或方程组
• 递推法
  • 等比数列
• 递归法
  • 斐波那契数列

五、设计模式

        设计模式这部分主要是多积累，在设计模式中最重要的是类和关系，对于有过开发经验能够看图写出代码的的童鞋来说这部分还是很简单的，常考的主要是关键字词和关系的调用。

   1、关键字

         abstract：声明抽象类或抽象方法。如果声明了抽象方法，则此方法必须在子类中进行重写。

         extends：类和类的继承关键字；

         implements：实现接口；
         interface：声明接口；
         static：静态成员，不需要实例化就能调用；
         super：调用父类的构造方法；操作父类被隐藏的成员变量和被覆盖的成员方法。

        在填写时，要根据题中给出的类图及题中上下文的代码确定要填写的内容，如果不能确定的可以查看C++类的设计模式，Java版的和C++版的是同样的设计模式，只是它们的语法规则不同。