软件工程习题 – 设计题

旨在通过题目理解设计题形式

考点：

1．系统概述以及自己负责的功能模块或子系统的描述；
2．绘制完整用例图，并对其中的3个用例进行用例描述；

1.实现概念结构设计，重点绘制ER图；
2.实现逻辑结构设计，重点设计数据库表以及绘制数据库表间的关系图。

1.实现类图建模；
2.绘制出相应的顺序图并生成协作图；
3.绘制相应的状态图；
4.绘制相应的活动图。

理解

上求职招聘系统中的求职者模块包含以下功能
修改密码、更新个人资料、搜索招聘信息、发布求职意向、下载简历模版、投递简历、查看个人信箱
1.对系统的求职者模块进行用况建模 （5分）

设计求职者实体类和求职信息实体类（标注它们之间的关系）。（5分）

用例图

例：

用例描述模板：

示例类图：

需求描述

筛选备选类
“小王”、“人”、“家里”很明显是系统外的概念，无须对其建模；

而“个人图书管理系统”、“系统”指的就是将要开发的系统，即系统本身，也无须对其进行建模；

“功能”、“新书籍”、“信息”、“记录”都是在描述需求时使用到的一些相关词语，并不是问题域的本质，因此先可以将其淘汰掉；

“计算机类”、“非计算机类”是该系统中图书的两大分类，因此应该对其建模，并改名为“计算机类书籍”和“非计算机类书籍”，以减少歧义；

“外借情况”则是用来表示一次借阅行为，应该成为一个候选类，多个外借情况将组成“外借情况列表”，而外借情况中一个很重要的角色是“朋友”—借阅主体。虽然到本系统中并不需要建立“朋友”的资料库，但考虑到可能会需要列出某个朋友的借阅情况，因此还是将其列为候选类。为了能够更好地表述，将“外借情况”改名为“借阅记录”，而将“外借情况列表”改名为“借阅记录列表”；

“购买金额”、“册数”都是统计的结果，都是一个数字，因此不用将其建模，而“特定时限”则是统计的范围，也无需将其建模；不过从这里的分析中，我们可以发现，在该需求描述中隐藏着一个关键类—书籍列表，也就是执行统计的主体。

得到候选类

书籍 计算机类书籍 非计算机类书籍
借阅记录 借阅记录列表 书籍列表

建模

限定符：
一本书只有一册，因此只能够被借一次，因此对于一本Book而言只能有一个RecordId与其对应

约束：
Book对象创建后就不能够被删除只能被修改，因此在Book类边上加上用自由文本写的约束 ；

一本书要么属于计算机类，要么属于非计算机类，因此在ItBook和OtherBook间加了 “{Xor}”约束

协作图

协作图

简单的状态图

需求描述

对于航班机票预订系统而言，显然包括的状态主要有
– 在刚确定飞机计划时，显然是没有任何预订的，并且在有人预订机票之前都将处于这种“无预订”状态
– 对订座而言显然有“部分预订”和“预订完”两种状态
– 而当航班快要起飞时，显然要“预订关闭”
总结一下，主要有四种状态：无预订、部分预订、预订完以及预订关闭

修改后