【新版】系统架构设计师 - 案例分析 - 软件工程

在这里插入图片描述

个人总结,仅供参考,欢迎加好友一起讨论

文章目录

  • 结构化分析SA
    • 数据流图DFD
    • 数据流图平衡原则
    • 答题技巧
    • 例题1
    • 例题2
  • 面向对象的分析OOA
    • 用例图
    • 用例模型
    • 细化用例描述
    • 用例关系【包含、扩展、泛化】
    • 分析模型
    • 定义概念类
    • 确定类之间的关系
    • 类图与对象图
    • 实体类 - 存储信息和相关行为的类
    • 控制类 - 控制其它类
    • 边界类 - 描述外部与系统内部交互的类
    • 顺序图(序列图)
    • 通信图(协作图)
    • 定时图(计时图)
    • 交互预览图
    • 状态图
    • 活动图
    • 构件图与包图
    • 部署图
    • 流程图
    • 其它图
    • 例题1
    • 例题2
    • 例题3
    • 例题4
    • 例题5
    • 例题6

结构化分析SA

【新版】系统架构设计师 - 案例分析 - 软件工程_第1张图片

数据流图DFD

【新版】系统架构设计师 - 案例分析 - 软件工程_第2张图片

【新版】系统架构设计师 - 案例分析 - 软件工程_第3张图片

【新版】系统架构设计师 - 案例分析 - 软件工程_第4张图片

【新版】系统架构设计师 - 案例分析 - 软件工程_第5张图片

数据流图平衡原则

【新版】系统架构设计师 - 案例分析 - 软件工程_第6张图片

答题技巧

题目描述可能是:

【新版】系统架构设计师 - 案例分析 - 软件工程_第7张图片

实体可能是:

  • 人物角色:如客户、管理员、主管、经理、老师、学生
  • 组织机构:如银行、供应商、募捐机构
  • 外部系统:如银行系统、工资系统、后台数据库(当要开发的是中间件时)

存储可能是:

  • 存储的文字特征:xx文件、xx表、xx库、xx清单、xx档案

数据流可能是:

  • 数据平衡原则

    1)顶层图与0层图对比,是否有顶层图有,但0层图无的数据流,或反之。

    2)检查图中每个加工,是否存在只有入没有出,或只有出没有入,或根据输入的数据无法产生对应的输出的情况。

  • 按题目说明与图进行匹配

    说明中的每一句话,都能与图中有对应关系,当把说明中的实体与数据流标识出来之后,容易缩小对应范围,找出纰漏。

加工名可能是:

  • 加工是用于处理数据流的,所以要补充加工名,可以把该加工涉及的数据流在说明中标识出来,再在数据流名称所在的句子中,找“动词+名词”的结构,分析是否可作为加工。
  • “动词+名词”,如:生成报告,发出通知,批改作业,记录分数,当然这只是普遍情况,也有例外,如物流跟踪、用户管理。

例题1

某公司拟开发一个商业情报处理系统,使公司能够针对市场环境的变化及时调整发展战略,以获取最大的商业利益。项目组经过讨论,决定采用结构化分析和设计方法。在系统分析阶段,为了更好地对情报数据处理流程及其与外部角色的关联进行建模,项目组成员分别给出了自己的设计思路:

  1. 小张提出先构建系统流程图(System Flow Charts),以便更精确地反映系统的业务处理过程及数据的输入和输出。
  2. 小李提出先构建系统数据流图(Data Flow Diagrams),来展现系统的处理过程和定义业务功能边界,并给出了情报分类子系统的0层和1层数据流图,后者如图所示。

【新版】系统架构设计师 - 案例分析 - 软件工程_第8张图片

项目组经讨论确定以数据流图作为本阶段的建模手段。工程师老王详细说明了流程图和数据流图之间的区别与联系,并指出了图中的数据流图存在的错误。

【问题1】

流程图和数据流图是软件系统分析设计中常用的两种手段,请用300字以内文字简要说明流程图与数据流图的含义及其区别,并说明项目组为何确定采用数据流图作为建模手段。

参考答案:

数据流图作为一种图形化工具,用来说明业务处理过程、系统边界内所包含的功能和系统中的数据流。流程图以图形化的方式展示应用程序从数据输入开始到获得输出为止的逻辑过程,描述处理过程的控制流。两者的区别如下:

  1. 数据流图中的处理过程可并行;流程图在某个时间点只能处于一个处理过程。
  2. 数据流图展现系统的数据流;流程图展现系统的控制流。
  3. 数据流图展现全局的处理过程,过程之间遵循不同的计时标准;流程图中处理过程遵循一致的计时标准。
  4. 数据流图适用于系统分析中的逻辑建模阶段;流程图适用于系统设计中的物理建模阶段。

【问题2】

请分析指出图中所示的数据流图存在的错误及其原因,并针对1层数据流图绘制出情报分类子系统的0层数据流图。

参考答案:

存在的错误有以下4种:

  1. “分类训练”加工:只有输入没有输出,产生数据黑洞。
  2. “分类处理”加工:有输出没有输入,无中生有。
  3. “规则文件”数据流:外部实体没有经过加工处理,直接到数据存储。
  4. “配置信息”数据流:外部实体之间没有加工处理,存在直接数据流。

【问题3】

高质量的数据流图是可读的、内部一致的并能够准确表示系统需求。请用300字以内文字说明在设计高质量的数据流图时应考虑的三个原则。

参考答案:

高质量数据流图设计时应考虑的三个原则如下:

  1. 复杂性最小化原则。数据流图分层结构就是把信息划分为小的且相对独立的一大批子集例子,这样就可以单独考察每一个数据流图。如果要了解某个过程更加详细的信息,可以跳转到该过程的下一层;如果要知道一个数据流图如何与其他数据流图相关联,可以跳转到上一层的数据流图进行考察。
  2. 接口最小化原则。接口最小化是复杂性最小化的一种具体规则。在设计模式时,应使得模型中各个元素之间的接口数或连接数最小化。
  3. 数据流一致性原则。一个过程和它的过程分解在数据流内容中是否有差别?是否存在有数据流出但没有相应的数据流入的加工,是否存在有数据流入但没有相应的数据流出的加工。

例题2

某公司欲建设一个房屋租赁服务系统,统一管理房主和租赁者的信息,提供快捷的租赁服务。本系统的主要功能描述如下:

1、登记房主信息。记录房主的姓名、住址、身份证号和联系电话等信息,并写入房主信息文件。

2、登记房屋信息。记录房屋的地址、房屋类型(如平房、带阳台的楼房、独立式住宅等)、楼层、租金及房屋状态(待租赁、已出租)等信息,并写入房屋信息文件。一名房主可以在系统中登记多套待租赁的房屋。

3、登记租赁者信息。记录租赁者的个人信息,包括:姓名、性别、住址、身份证号和电话号码等,并写入租赁者信息文件。

4、安排看房。已经登记在系统中的租赁者,可以从待租赁房屋列表中查询待租赁房屋信息。租赁者可以提出看房请求,系统安排租赁者看房。对于每次看房,系统会生成一条看房记录并将其写入看房记录文件中。

5、收取手续费。房主登记完房屋后,系统会生成一份费用单,房主根据费用单交纳相应的费用。

6、变更房屋状态。当租赁者与房主达成租房或退房协议后,房主向系统提交变更房屋状态的请求。系统将根据房主的请求,修改房屋信息文件。

【问题1】

若来用结构化方法对房屋租赁服务系统进行分析,得到如下图所示的顶层DFD,使用题干中给出的词语,给出图中外部实体E1 ~ E2、加工P1 ~ P6以及数据存储D1 ~ D4的名称。

【新版】系统架构设计师 - 案例分析 - 软件工程_第9张图片

参考答案:

E1:房主

E2:租赁者

P1:登记房主信息

P2:登记房屋信息

P3:登记租赁者信息

P4:查询租赁房屋信息

P5:安排看房

P6:变更房屋状态

D1:房主信息文件

D2:租赁者信息文件

D3:房屋信息文件

D4:看房记录文件

【问题2】

若采用信息工程(Information Engineering)方法对房屋租赁服务系统进行分析,得到如下图的ERD。请给出

图中实体(1)~(5)的名称。

【新版】系统架构设计师 - 案例分析 - 软件工程_第10张图片

参考答案:

(1)房主

(2)房屋

(3)房屋信息文件

(4)租赁者

(5)看房记录

【问题3】

(1)信息工程方法中的’实体(entity) ”与面向对象方法中的“类(class) ”之间有哪些不同之处?

(2)在面向对象方法中通常采用用例(Use Case)来捕获系统的功能需求。用例可以按照不同的层次来进行划分,其中的Essential Use Cases和Real Use Cases有哪些区别?

参考答案:

(1)实体用于数据建模,而类用于面向对象建模。实体只有属性,而类有属性和操作。

(2)Essential Use Cases可翻译为抽象用例,Real Use Cases可翻译为基础用例。他们是区别在于:基础用例是实实在在与用户需求有对应关系的用例,是从用户需求获取的渠道得到的,而抽象用例是从基础用例中抽取的用例的公共部分,是为了避免重复工作,优化结构而提出的用例。

面向对象的分析OOA

【新版】系统架构设计师 - 案例分析 - 软件工程_第11张图片

用例图

用例图描述一组用例、参与者及它们之间的关系。如下图:

  • 用户角度描述系统功能
  • 参与者是外部触发因素
  • 用例是功能单元

【新版】系统架构设计师 - 案例分析 - 软件工程_第12张图片

用例模型

用例模型的建立过程:

  1. 第一步,识别参与者【参与者:用户、组织、外部系统,时间】
  2. 第二步,合并需求获得用例
  3. 第三步,细化用例描述
  4. 第四步,调整用例模型(可选步骤)【关系包括:包含关系、扩展关系、泛化关系】

细化用例描述

示例:登录用例,如下图:

【新版】系统架构设计师 - 案例分析 - 软件工程_第13张图片

用例关系【包含、扩展、泛化】

包含关系【使用关系】:从多个用例中提取公共行为,提取出来的公共用例称为抽象用例,而把原始用例称为基本用例。如下:

【新版】系统架构设计师 - 案例分析 - 软件工程_第14张图片

扩展关系:一个用例明显地混合了两种或两种以上的不同场景,即根据情况可能发生多种分支,则可以将这个用例分为一个基本用例和一个或多个扩展用例。如下:

【新版】系统架构设计师 - 案例分析 - 软件工程_第15张图片

泛化关系:当多个用例共同拥有一种类似的结构和行为的时候,可以将它们的共性抽象成为父用例,其他的用例作为泛化关系中的子用例。子用例继承了父用例所有的结构、行为和关系。如下:

【新版】系统架构设计师 - 案例分析 - 软件工程_第16张图片

示例,如下:

【新版】系统架构设计师 - 案例分析 - 软件工程_第17张图片

示例:在某银行业务的用例模型中:“取款”和“存款”两个用例中都需要执行查询余额的功能,将查询余额提取成独立的用例,那么“取款”和“存款”用例与“查询余额”用例之间的关系属于( )。

解: 包含关系

分析模型

分析模型的建立过程:

  1. 第一步,定义概念类
  2. 第二步,确定类之间的关系
  3. 第三步,为类添加职责
  4. 第四步,建立交互图
  5. 第五步,分析模型的详细程度问题

定义概念类

  1. 阅读和理解需求文档或用例描述。

  2. 筛选出名词或名词短语,建立初始类清单(候选类)。

  3. 将候选类分成三类,分别是显而易见的类、明显无意义的类和不确定类别的类。

  4. 舍弃明显无意义的类。

    1)去除相同含义的

    2)去除不属于系统范围内的

    3)去除没有特定独立行为的

    4)去除含义解释不清楚的

    5)去除属于另一个类属性或行为的

  5. 小组讨论不确定类别的类,直到将它们都合并或调整到其他两个类别,并进行相应的操作。

确定类之间的关系

  • 依赖关系,一个事物发生变化影响另一个事物。

  • 泛化关系,特殊/一般关系。

  • 关联关系,描述了一组链,链是对象之间的连接。

    聚合关系,整体与部分生命周期不同。

    组合关系,整体与部分生命周期相同。

  • 实现关系,接口与类之间的关系。

【新版】系统架构设计师 - 案例分析 - 软件工程_第18张图片

示例:UML用关系把事物结合在一起,( )描述一个事物发生变化会影响另一个事物的语义。( )描述特殊元素的对象可替换一般元素的对象。

解:依赖关系,泛化关系

类图与对象图

类图(class diagram),类图描述一组类、接口、协作和它们之间的关系。

对象图(object diagram),对象图描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。

实体类 - 存储信息和相关行为的类

  • 一定有属性,但不一定有操作。
  • 反映的信息需要在系统中处理,并需要进行持久化存储。持久化存储可与由实体类来实现,也可以设计专门的数据访问类来完成。通常每个实体类在数据库中有相应的表,实体类中的属性对应数据库表中的字段。
  • 例如:事件、人员或者一些现实生活中的对象。实体类通常都是永久性的,它们所具有的属性和关系是长期需要的,有时甚至在系统的整个生存期都需要。

控制类 - 控制其它类

  • 控制用例工作的类
  • 体现应用程序的执行逻辑,描述一个用例所具有的事件流控制行为,控制一个用例中的事件顺序。
  • 当业务主角通过边界类来执行用例的时候,产生一个控制类对象,在用例被执行完后,控制类对象会被销毁。

边界类 - 描述外部与系统内部交互的类

  • 用于系统接口与系统外部进行交互,边界类依赖于系统外部的环境,比如用户的操作习惯、外部的条件的限制等。

  • 边界类位于系统与外界的交界处,窗体、报表、以及表示通讯协议的类、直接与外部设备交互的类、直接与外部系统交互的类等都是边界类。

  • 一个系统可能会有多种边界类:

    用户界面类 - 帮助与系统用户进行通信的类

    系统接口类 - 帮助与其他系统进行通信的类

    设备接口类 - 为用来监测外部事件的设备(如传感器)提供接口的类

顺序图(序列图)

顺序图(Sequence Diagram,序列图)。顺序图是一种交互图(Interaction Diagram),它强调对象之间消息发送的顺序,同时显示对象之间的交互。(构成顺序图的基本元素包括对象、生命线和消息。)

【新版】系统架构设计师 - 案例分析 - 软件工程_第19张图片

示例:某公司欲开发一个在线交易系统。为了能够精确表达用户与系统的复杂交互过程,应该采用UML的( )进行交互过程建模。

解:顺序图

区分顺序图和通信图的特点

顺序图,强调的是交互和顺序;通信图,强调的对象之前的关系,并不专门提出顺序。

通信图(协作图)

通信图(Communication Diagram)。通信图也是一种交互图,它强调对象之间存在的消息收发关系,而不专门突出这些消息发送的时间顺序。

【新版】系统架构设计师 - 案例分析 - 软件工程_第20张图片

顺序图(序列图) 通信图(协作图)
序列图主要用来更直观的表现各个对象交互的时间顺序,将体现的重点放在以时间为参照,各个对象发送、接收消息,处理消息,返回消息的时间流程顺序,也称为时序图。 协作图是一种类图,强调参与交互的各个对象的结构信息和组织。
强调时间顺序 强调关系结构

定时图(计时图)

定时图也叫计时图,也是一种交互图,用于展示交互过程中的真实时间信息,具体描述对象状态变化的时间点以及维持特定状态的时间段。

定时图,强调的是时间点上的状态。

【新版】系统架构设计师 - 案例分析 - 软件工程_第21张图片

交互预览图

交互概览图强调控制流的交互图。交互概览图是活动图和顺序图的混合物。

活动图的变体,描述业务过程中的控制流概览,软件过程中的详细逻辑概览,以及将多个图进行连接,抽象掉了消息和生命线。

状态图

状态图(State Diagram)是对类描述的补充。用于展现此类对象所具有的可能状态,以及其些事件发生时其状态转移情况。

【新版】系统架构设计师 - 案例分析 - 软件工程_第22张图片

示例:在订单处理的过程中,会员可以点击“取消订单”取消该订单。如果支付失败,该订单将被标记为挂起状态,可后续重新支付,如果挂起超时30分钟未支付,系统将自动取消该订单。订单支付成功后,系统判断订单类型:

(1)对于常规订单,标记为备货状态,订单信息发送到货运部,完成打包后交付快递发货。

(2)对于定制订单,会自动进入定制状态,定制完成后交付快递发货。会员在系统中点击“收货”按钮变为收货状态,结束整个订单的处理流程。

【新版】系统架构设计师 - 案例分析 - 软件工程_第23张图片

区分状态图和活动图的特点

状态图,强调的是类对象具有的状态;活动图,主要强调处理流程和数据流转,各种执行流程。

活动图

活动图(Activity Diagram)是一种特殊的状态图。活动图描述一个操作中要进行的各项活动的执行流程。同时,也常被用来描述一个用例的处理流程或者某种交互流程。

活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。它强调对象间的控制流程。

普通活动图

【新版】系统架构设计师 - 案例分析 - 软件工程_第24张图片

泳道活动图

【新版】系统架构设计师 - 案例分析 - 软件工程_第25张图片

示例:( )适用于描述复杂算法的执行流程。

解:活动图

状态图 活动图
用来描述一个特定的对象所有可能的状态,以及由于各种事件的发生而引起的状态之间的转移和变化。 将进程或其他计算的结构展示为计算内部一步步的控制流和数据流,主要用来描述系统的动态视图。
状态图主要描述行为的结果。 活动图主要描述行为的动作。

构件图与包图

构件图(Component Diagram)。构件图描述一个封装的类和它的接口、端口,以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。对于由小的部件构建大的系统来说,构件图是很重要的。构件图是类图的变体。

包图,包的图标像是一个带标签的文件夹,包的基本思想是把共同工作的元素放到一个文件夹中。例:多个类或构件组成了一个子系统,就可以将它们放到一个包中。

构件图和包图很好区分,这里不做强调了。

部署图

部署图(DeploymentDiagram)。部署图描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图,通常一个节点包含一个或多个部署图。

【新版】系统架构设计师 - 案例分析 - 软件工程_第26张图片

流程图

【新版】系统架构设计师 - 案例分析 - 软件工程_第27张图片

流程图 活动图
描述处理过程。主要控制结构是顺序、分支和循环,各个处理过程之间有严格的顺序和时间关系。 描述的是对象活动的顺序关系所遵循的规则,它着重表现的是系统的行为,而非系统的处理过程。
不能表示并发活动的情形。
面向过程。
能够表示并发活动的情形。
面向对象。

其它图

考查的并不多,不在阐述

例题1

某软件公司拟为物流企业开发一套库存管理系统,该系统的部分需求陈述如下:

  1. 库存管理系统主要包括货物入库管理、货物出库管理、仓库管理、统计报表和系统管理等功能。
  2. 库存管理系统的用户包括仓库管理员、仓库经理和系统管理员,用户必须在注册后才能使用系统功能;用户可以选择使用邮件注册或电话注册。
  3. 仓库管理员在进行出入库操作前必须先登录;仓库经理可以通过系统查看统计报表,如果前一个月的报表未生成则系统自动生成统计报表,否则直接显示。
  4. 系统管理员可以在系统中设置仓库温度范围,当仓库内温度超过最高值或者低于最低值时,系统自动调用温控管理操作,连接温度调节系统进行制冷或加热。
  5. 仓库管理功能要求每个月1日零点对前一个月货物入库和出库记录进行数据汇总操作。项目组决定构造用例模型以描述系统需求。

【问题1】

用例建模的首要任务是识别系统中的参与者。请根据题目中所描述的需求,识别出系统中有哪些参与者?

参考答案:

用例模型的参与者:仓库管理员、仓库经理、系统管理员、时间、温度、温度调节系统。

【问题2】

用例建模的主要工作是书写用例规约。用例规约通常包括哪几部分内容?

参考答案:

用例规约:用例名称、简要说明、事件流、非功能需求、前置条件、后置条件、扩展点、优先级。

【问题3】

建立了用例模型后,可以利用用例之间的关系调整用例模型,用例之间的关系包括哪几种?对于每种关系,请根据题目中所描述的需求分别给出一组用例。

参考答案:

建立了用例模型后,可以利用用例之间的关系调整用例模型,用例之间的关系包括哪几种?对于每种关系,请根据题目中所描述的需求分别给出一组用例。

用例之间的关系包括:包含关系、扩展关系、泛化关系。

“出入库操作”与“登录”属于包含关系。

“查看统计报表”与“生成统计报表”属于扩展关系。

“用户注册”与“邮件注册”和“电话注册”属于典型的泛化关系。

例题2

某软件公司为电子商务企业开发一套网上交易订单管理系统,以提升服务的质量和效率。在项目之初,项目组决定采用面向对象的开发方法进行系统开发,并对系统的核心业务功能进行了分析,具体描述如下:

  1. 注册用户通过商品信息页面在线浏览商品,将需要购买的商品添加进购物车内,点击“结算”按钮后开始录入订单信息。
  2. 用户在订单信息录入页面上选择支付方式,填写并确认收货人、收货地址和联系方式等信息。点击“提交订单”按钮后产生订单,并开始进行订单结算。
  3. 订单需要在30分钟内进行支付,否则会自动取消,用户也可以手工取消订单。
  4. 用户支付完成,经确认后,系统开始备货,扣除该商品可接单数量,并移除用户购物车中的所有商品资料。
  5. 生成订单表单,出货完毕,订单生效。为用户快递商品,等待用户接收。
  6. 用户签收商品,交易完成。

【问题1】

识别设计类是面向对象设计过程中的重要工作,设计类表达了类的职责,即该类所担任的任务。请用300字以内的文字说明设计类通常分为哪三种类型、每种类型的主要职责,并针对题干描述案例涉及的具体类为每种类型的设计类举出2个实例。

参考答案:

实体类。实体类映射需求中的每个实体,保存需要存储在永久存储体中的信息,例如,用户、商品等。

控制类。控制类是用于控制用例工作的类,用于对一个或几个用例所特有的控制行为进行建模。例如,结算、备货等。

边界类。边界类用于封装在用例内、外流动的信息或数据流。例如,浏览器、购物车等。

【问题2】

在面向对象的设计过程中,活动图(activity diagram)阐明了业务用例实现的工作流程。请用300字以内的文字给出活动图与流程图(flow chart)的三个主要区别。

参考答案:

活动图描述的是对象活动的顺序关系所遵循的规则,它着重表现系统的行为,而非处理过程;而流程图着重描述处理过程。

流程图一般都限于顺序进程,而活动图则可以支持并发进程。

活动图是面向对象的,而流程图是面向过程的。

【问题3】

在面向对象的设计过程中,状态图(state chart diagram)描述了一个实体基于事件反应的动态行为。请根据题干描述,填写图中的(a)~ (e)空白,完成订单处理的状态图。

【新版】系统架构设计师 - 案例分析 - 软件工程_第28张图片

参考答案:

(a)取消

(b)待结算

(c)大于30分钟

(d)订单生效

(e)用户签收

例题3

某软件公司为共享单车租赁公司开发一套单车租赁服务系统,公司项目组对此待开发项目进行了分析,具体描述如下:

  1. 用户(非注册用户)通过手机向租赁服务系统进行注册,成为可租赁共享单车的合法用户,其中包括提供身份、手机号等信息,并支付约定押金。
  2. 将采购的共享单车注册到租赁服务系统后方可投入使用。即将单车的标识信息(车辆编号、二维码等)录入到系统。
  3. 用户(注册或非注册用户)通过手机查询可获得单车的地理位置信息以便就近取用。
  4. 用户(注册用户)通过手机登录到租赁服务系统中,通过扫描二维码或输入车辆编号以进行系统确认,系统后台对指定车辆状态(可用或不可用),以及用户资格进行确认,通过确认后对车辆下达解锁指令。
  5. 用户在用完车辆后关闭车锁,车辆自身将闭锁状态上报到租赁服务系统中,完成车辆状态的更新和用户租赁费用结算。
  6. 系统应具备一定的扩容能力,以满足未来市场规模扩张的需要。

项目组李工认为该系统功能相对独立,系统可分解为不同的独立功能模块,适合采用结构化分析与设计方法对系统进行分析与设计。但王工认为,系统可管理的对象明确,而且项目团队具有较强的面向对象系统开发经验,建议采用面向对象分析与设计方法。经项目组讨论,决定采用王工的建议,采用面向对象分析与设计方法开发系统。

【问题1】

在系统分析阶段,结构化分析和面向对象分析方法主要分析过程和分析模型均有所区别,请将(a)~(g)各项内容填入下表中的(1)~(4)处对应位置。

在这里插入图片描述

(a)确定目标系统概念类

(b)实体关系图(ERD)

(c)用例图。

(d)通过功能分解方式把系统功能分解到各个模块中。

(e)交互图。

(f)数据流图(DFD)

(g)建立类间交互关系

参考答案:

(1):(d)

(2):(b)(f)

(3):(a)(g)

(4):(c)(e)

【问题2】

请分析下面A ~ Q所列出的共享单车租赁服务系统中的概念类及其方法,在下图所示用例图(1)~(12)处补充所缺失信息。

【新版】系统架构设计师 - 案例分析 - 软件工程_第29张图片

A.用户,B.共享单车,C.用户管理,D.注册,E.注销,F.用户查询,G.单车管理,

H.租赁,I.归还,J.单车查询,K.费用管理,L.保证金管理,M.租赁费管理,N.数据存储管理,

O.用户数据存储管理,P.单车数据存储管理,Q.费用结算,R.身份认证

参考答案:

(1)D:注册

(2)F:用户查询

(3)C:用户管理

(4)R:身份认证

(5)A:用户

(6)N:数据存储管理

(7)P:单车数据存储管理

(8)I:归还

(9)B:共享单车

(10)K:费用管理

(11)L:保证金管理

(12)Q:费用结算

【问题3】

随着共享单车投放量以及用户量的增加会存在系统性能或容量下降问题,请用 200 字以内的文字说明,在系统设计之初,如何考虑此类问题?

参考答案:

(1)采用集群技术进行服务器的水平扩展。

(2)采用负载均衡技术,提升并发处理能力。

(3)采用分布式存储方式,将各地区数据分散存储,减少压力

例题4

某软件公司拟开发一套博客系统,要求能够向用户提供一个便捷发布自己心得,及时有效地与他人进行交流的平台。新用户发布个人博客之前,需要创建一个新的博客账户,以下为新用户注册的操作行为:

(a)向系统请求创建一个新的博客账户。

(b)输入个人详细信息。

(c)使用证件数据库验证个人详细信息。

(d)选择账户类型。

(e)身份验证成功,创建新的博客账户。

(f)用户身份信息验证不成功。

(g)以电子邮件的方式将账户详细信息发送给用户。

(h)博客账户申请被拒绝。

【问题1】

在结构化和面向对象的软件分析过程中,通常会使用到数据流图、活动图和流程图,请分别描述这三种模型的特点和适用场景。

参考答案:

数据流图:

通过系统内数据的流动来描述系统功能的一种方法,强调系统中的数据流动。其基本元素包括:数据流,外部实体,加工,数据存储。主要用于结构化需求分析,为系统做功能建模。

活动图:

与流程图类似,但可以表现并行执行。用于面向对象分析与设计建模。

流程图:

能清晰展现业务执行的流程顺序,强调控制流。用于结构化需求分析与结构化设计,为系统梳理业务流程。

【问题2】

采用用例图和用例描述建模系统需求,请使用题干给出的(a)~(h),完善“博客账户创建用例描述”中的(1)~(6),如下表所示。将正确答案填在答题纸上。

【新版】系统架构设计师 - 案例分析 - 软件工程_第30张图片

参考答案:

基本流程步骤:

1 向系统请求创建一个新的博客账户

2 选择账户类型

3 输入个人详细信息

4 使用证件数据库验证个人详细信息

6 以电子邮件方式将账户详细信息发送给用户

扩展流程步骤:

2 博客账户申请被拒绝

具体:

(1)===(a)

(2)===(d)

(3)===(b)

(4)===(c)

(5)===(g)

(6)===(h)

【问题3】

需求评审是通过将需求规格说明书递交给相关人员检查,以发现其中存在缺陷的过程。在需求工程中,需求评审是一个非常重要的过程。结合题干案例,请用300字以内的文字简要说明需求评审的内容及作用。

参考答案:

需求评审内容:

  1. SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。
  2. SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
  3. 需求是完整的和高质量的。
  4. 需求的表示在所有地方都是一致的。
  5. 需求为继续进行系统设计、实现和测试提供了足够的基础。
  6. 用例优先级合理度评估。

本例中存在需求描述不完整的情况,如:谁向系统请求?输入个人详细信息要输入哪些?选择账户类型,有哪些账户类型供选择?都未明确描述

例题5

某商校拟开发一套图书馆管理系统,在系统分析阶段,系统分析师整理的核心业务流程与需求如下:系统为每个读者建立一个账户,并给读者发放读者证(包含读者证号、读者姓名),账户中存储读者的个人信息、借阅信息以及预订信息等,挂有读者证可以借阅图书、返还图书、查询图书信息、预订图书、取消预订等。

在借阅图书时,需要输入读者所借阅的图书名、ISBN号,然后输入读者的读者证号,完成后提交系统,以进行读者验证,如果读者有效,借阅请求被接受,系统查询读者所借阅的图书是否存在,若存在, 则读者可借出图书,系统记录借阅记录:如果读者所借阅的图书已被借出,读者还可预订该图书。读者如期还书后,系统清除借阅记录,否则需缴纳罚金,读者还可以选择续借图书。

【问题1】

采用面向对象方法进行软件系统分析与设计时,一项重要的工作是进行类的分析与设计。请用200字以内的文字说明分析类图与设计类图的差异。

参考答案:

分析类图:在需求分析阶段,类图是研究领域中的概念;分析类图主要用于描述应用领域中的概念,类图中的类从领域中得出,从需求中获取。

设计类图:在设计阶段,类图重点描述类与类之间的接口;设计类图用于描述软件的接口部分,而不是软件的实现部分,设计类图更易于开发者之间的相互理解和交流;

设计类图通常是在分析类图的基础上进行细化和改进的。

【问题2】

设计类图的首要工作是进行类的识别与分类,该工作可分为两个阶段:首先,采用识别与筛选法,对需求分析文档进行分析,保留系统的重要概念与属性,删除不正确或冗余的内容:其次,将识别出来的类按照边界类、实体类和控制类等三种类型进行分类。 请用200字以内的文字对边界类,实体类和控制类的作用进行简要解释,并对下面给出的候选项进行识别与筛选,将合适的候选项编号填入下表中的(1)~(3)空白处,完成类的识别与分类工作。

【新版】系统架构设计师 - 案例分析 - 软件工程_第31张图片

候选项:

a)系统管理员

b)图书管理员

c)读者

d)读者证

e)账户

f)图书

g)借阅

h)归还

i)预订

j)罚金

k)续借

l)借阅记录

参考答案:

边界类:d

实体类:a、b、c、e、f、j、l

控制类:g、h、i、k

例题6

某公司拟开发一套手机通讯录管理软件,实现对手机中联系人的组织与管理。公司系统分析师王工首先进行了需求分析,得到的系统需求列举如下:

用户可通过查询接口查找联系人,软件以列表的方式将查找到的联系人显示在屏幕上。显示信息包括姓名、照片和电话号码。用户点击手机的“后退”按钮则退出此软件。点击联系人列表进入联系人详细信息界面,包括姓名、照片、电话号码、电子邮箱、地址和公司等信息。为每个电话号码提供发送短信和拨打电话两个按键实现对应的操作。用户点击手机的“后退”按钮则回到联系人列表界面。在联系人详细信息界面点击电话号码对应的发送短信按键则进入发送短信界面。界面包括发送对象信息显示、短信内容输入和发送按键三个功能。用户点击发送按键则发送短信并返回联系人详细信息界面;点击“后退”按钮则回到联系人详细信息界面。在联系人详细信息界面内点击电话号码对应的拨打电话按键则进入手机的拨打电话界面。在通话结束或挂断电话后返回联系人详细信息界面。

在系统分析与设计阶段,公司经过内部讨论,一致认为该系统的需求定义明确,建议基于公司现有的软件开发框架,采用新的基于模型驱动架构的软件开发方法,将开发人员从大量的重复工作和技术细节中解放出来,使之将主要精力集中在具体的功能或者可用性的设计上。公司任命王工为项目技术负责人,负责项目的开发工作。

【问题1】

王工经过需求分析,首先建立了该手机通信录管理软件的状态机模型,如图 2-2 所示。请对题干需求进行仔细分析,填写下图中的(1)~(5)处空白。

【新版】系统架构设计师 - 案例分析 - 软件工程_第32张图片

参考答案:

(1)点击“后退”按钮

(2)联系人详细信息界面

(3)点击发送给按键或点击后退按钮

(4)点击拨打电话按键

(5)拨打电话界面

你可能感兴趣的:(软考,-,系统架构设计师,软考,系统架构设计师)