软件工程习题

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

考点：

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

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

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

理解

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

创建活动图描述修改密码用况（分泳道）（5分）

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

一家工厂的采购部每天需要一张定货报表，报表按零件编号排序，表中列出所有需要再次定货的零件。对于每个需要再次定货的零件应该列出下述数据；零件编号、零件名称、定货数量、目前价格、主要供应者和次要供应者。零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给定货系统。当某种零件的库存数量少于库存量临界值时就应该再次定货。

请画出上述定货系统的数据流图（顶层和分层）。

用例图

例：

组成元素：
图中的元素包括：参与者、用例、一个方框和一些表示关系的连接线

所有的用例都位于方框之内，该方框称为“系统边界”

参与者与用例的关系：在参与者和用例之间的关联是用一根带箭头的线来表示的
用例之间的关系：1）包含关系 2）扩展关系 3）泛化关系

泛化关系：可以用来表示参与者与参与者之间，用例与用例之间的特殊/一般化关系

用例描述模板：

ER图

设计数据库表以及绘制数据库表间的关系图

类图

示例类图：

阅读:
读出类：图中共有7个类，Order、OrderItem、Customer、Consignee、DeliverOrder、Peddlery、Prodcut

读出关系：从图中关系最复杂（也就是线最密集）的类开始阅读，本图中最复杂的就是Order类。
1）OrderItem和Order之间是组合关系，根据箭头的方向可知Order包含了OrderItem。
2）Order类和Customer、Consignee、DeliverOrder是关联关系。也就是说，一个订单和客户、收货人、送货单是相关的。

需求描述

小王是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计

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

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

很明显“书籍”是一个很重要的类，而“书名”、“作者”、“类别”、“出版社”、“书号”则都是用来描述书籍的基本信息的，因此应该作为“书籍”类的属性处理，而“规则”是指书号的生成规则，而书号则是书籍的一个属性，因此“规则”可以作为编写“书籍”类构造函数的指南。

“基本信息”则是书名、作者、类别等描述书籍的基本信息统称，“关键字”则是代表其中之一，因此无需对其建模；

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

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

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

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

得到候选类

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

建模

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

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

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

顺序图

消息分为五种：调用、返回、发送、创建和销毁

协作图

需求描述

顺序图

协作图

状态图

简单的状态图

源状态：即受转换影响的状态
目标状态：当转换完成后对象的状态
触发事件：用来为转换定义一个事件，包括调用、改变、信号、时间四类事件
监护条件：布尔表达式，决定是否激活转换、
动作：转换激活时的操作

与状态off相关的转换有两个，其触发事件都是turnOn，只不过其监护条件不同。如果对象收到事件turnOn，那么将判断壶中是否有水；如果[没水]，则仍然处于off状态；如果[有水]则转为on状态，并执行“烧水”动作

而与状态on相关的转换也有两个，如果“水开了”就执行turnOff，关掉开关；如果烧坏了，就进入了终态了

复杂的状态图

需求描述

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

活动图

简单的活动图

修改后

带泳道