2021系统分析师论文题目记忆

试题一：论面向对象的系统分析方法及应用

OOA的基本任务是运用OO方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反映问题域和系统功能的OOA模型及其详细说明。
OOA模型独立于具体实现，即不考虑与系统具体实现有关的因素，这也是OOA和OOD的区别之所在。OOA的任务是“做什么”，OOD的任务是“怎么做”。

建立用例模型：

• 识别参与者：
  参与者是与系统交互的所有事物，该角色不仅可以由人承担，还可以是其他系统和硬件设备，甚至是系统时钟。
  （1）其他系统：当系统需要与其他系统交互时，其他系统就是一个参与者。例如，对某企业的在线教育平台系统而言，该企业的OA系统就是一个参与者。
  （2）硬件设备：如果系统需要与硬件设备交互，硬件设备就是一个参与者。例如，在开发集成电路（Integrated Circuit, IC）卡门禁系统时，IC卡读写器就是一个参与者。
  （3）时钟：当系统需要定时触发时，时钟就是一个参与者。例如，开发在线测试系统中的“定时交卷”功能时，就需要引入时钟作为参与者。
  要注意的是，参与者一定在系统之外，不是系统的一部分。可以通过下列问题来帮助系统分析师发现系统的参与者：谁使用这个系统？谁安装这个系统？谁启动这个系统？谁维护这个系统？谁关闭这个系统？哪些（其他的）系统使用这个系统？谁从这个系统获取信息？谁为这个系统提供信息？是否有事情自动在预计的时间发生？
  执行系统某项功能的参与者可能有多个，但这多个参与者在使用系统时会有不同的职责划分，根据职责的重要程度不同，有主要参与者和次要参与者之分。主要参与者是从系统中直接获得可度量价值的参与者，次要参与者的需求驱动了用例所表示的行为或功能，在用例中起支持作用，帮助主要参与者完成他们的工作，次要参与者不能脱离主要参与者而存在。开发用例的重点是要找到主要参与者。
• 合并需求获得用例
  将参与者都找到之后，接下来就是仔细地检查参与者，为每一个参与者确定用例。首先，要将获取到的需求分配给与其相关的参与者，以便可以针对每个参与者进行工作，而无遗漏；其次，进行合并操作。在合并之前，要明确为什么要合并，知道了合并的目的，才可能选择正确的合并操作。合并后，将产生用例。将识别到的参与者和合并生成的用例，通过用例图的形式整理出来，以获得用例模型的框架，如图11-10所示。
  图11-10　用例图示例
  在确定用例的过程中，需要注意以下问题：
  （1）用例命名。用例的命名应该注意采用“动词（短语）＋名词（短语）”的形式，例如，“开通课程”和“课程测试”等。而且，最好能够对用例进行编号，这也是实现需求跟踪管理的重要技巧，通过编号可以将用户的需求落实到特定的用例中去。
  （2）不能混淆用例和用例所包含的步骤。例如，“开通课程”功能要经过验证学员信息、检查学员权限、保存开通记录、修改课程选修人数等步骤才能完成，在系统中这些步骤不能作为单独的功能对外提供，它们只是一个用例所包含的事件流，或是是用例的子功能。
  （3）注意区分业务用例和系统用例。当针对整个业务领域建模时，需要使用业务用例，其中会涉及大量的人工活动，例如，在线教育平台系统中有一项重要工作是“编写教材”，这就是业务用例，是信息系统无法完成的。信息系统作为整个业务系统的一部分，只负责实现系统的部分功能，因此，只需要识别出系统用例，而不需考虑业务用例。
• 细化用例描述
  用例建模的主要工作是书写用例规约（use case specification），而不是画图。用例模板为一个给定项目的所有人员定义了用例规约的结果，其内容至少包括用例名、参与者、目标、前置条件、事件流（基本事件流和扩展事件流）和后置条件等，其他的还可以包括非功能需求和用例优先级等。
  一个较为复杂的系统会有较多的用例，为便于理解，可以为它们建立多张用例图。更为复杂的情况将导致所有用例难以维持一种平面结构，这时可以对用例进行分组。UML使用用例主题划分用例图，一组用例放置在以主题命名的方框中（类似于系统边界），每个主题中可以包含多个用例图。
  用例的描述可以迭代完成，先对一些重要的用例编制相对细致的用例描述，对于一些不重要的用例，可以留待以后再补充完成。用例描述通常包括以下几个部分：
  （1）用例名称。用例名称应该与用例图相符，并写上其相应的编号。
  （2）简要说明。对用例为参与者所传递的价值结果进行描述，应注意语言简要，使用用户能够阅读的自然语言。
  （3）事件流。事件流是指当参与者和系统试图达到一个目标时所发生的一系列活动，也就是用例所完成的工作步骤。在编写时应注意使用简单的语法，主语明确，语义易于理解；明确写出“谁控制球”，也就是在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制；从俯视的角度来编写，指出参与者的动作，以及系统的响应；描述用户意图和系统职责，而不叙述具体的行为和技术细节，特别是有关用户界面的细节。
  执行一个用例的事件流有多种可能的路线，其中主事件流（基本事件流）是指能够满足目标的典型的成功路径，主事件流通常不包括任何条件和分支，符合大多数人的期望，从而更容易理解和扩展；备选事件流（扩展事件流）也称为备选路径，是完成用例可能出现失败的情况、分支路径或扩展路径，为了不影响用例活动清晰的主线，将这些分支处理全部