文章目录
除09+15
20上
20上-结构化分析
问题1：
问题2：
问题3：
问题4：
回答1：
E1=检测设备； E2=管理员；E3=检测业务员；E4=监控人员；
问题2：
D1=模型信息；D2=检测信息；D3=基础信息；
# D1=模型信息表；D2=检测信息表；D3=基础信息表；
问题3：
数据流-检测信息 起点：D2 终点：P3
数据流-监控规则 起点：D3 终点：P5
数据流-基础信息 起点：D3 终点：P6
数据流-检测结果信息 起点：D2 终点：P5 错误
# 数据流-检测信息 起点：P2 终点：P3
# 数据流-远程控制命令 起点：E3 终点：P5
问题4：
根据检测模型和检测质量标准对图像采集收到的所有产品的检测信息中的所有图像进行检测；
if 一个产品的的一个图像检测不合格
该产品不合格；
检测结果包括：产品型号和不合格类型；
else
该产品合格；
###
接收到产品检测信息
对所有图像进行检测
if 一个产品的一张图像不合格
then 该产品不合格
不合格的产品检测结果包括：产品型号和不合格类型
endif
20上-数据库分析
问题1：
问题2：
问题3：
问题4：
回答1：
分公司：经理 联系1 = 1：1；
分公司：业务部 联系2 = 1：n；
业务部：主管 联系3 = 1：1；
业务部：职员 联系4 = 1：n；
问题2：
a = 经理号、电话；
b = 地址、分公司编号；
c = 所属业务部编号；
# b = 地址、分公司编号、主管编号；
问题3：
分公司关系模式：主键=分公司编号，外键=经理号；
业务部关系模式：主键=业务部编号，外键=分公司编号；
# 业务部关系模式：主键=业务部编号，外键=分公司编号、主管号；
问题4：
职员关系模式中，每个职员多名家属成员，也就是一个职员会对应多条记录；
解决方式：该表的主键改由职员号、所属业务部门、家庭成员共同决定；
# 职员关系模式存在数据冗余，修改异常，插入异常，删除异常等情况；
数据冗余表现：家庭成员信息与职员信息关联，该情况下同一个职员的不同家庭成员信息所对应的职员信息将被重复存储；
插入异常：若职员尚无家庭成员信息，但数据库又要求至少一个成员信息，则会产生异常；
修改异常：当某个职员的家庭成员信息发生变化时，例如添加新的家庭成员、修改已有的家庭成员信息或删除不再相关的家庭成员，需要对每一个涉及的家庭成员进行更新操作，容易引发一致性问题。
删除异常：若需删除某位职员信息，则该职员的家庭成员信息也一并删除，可能丢失重要的统计数据；
应将“职员”关系模式进行分解，分解为：
职员1（职员号、姓名、岗位、所属业务部编号、电话）
职员2（职员号、家庭成员姓名、成员关系）
20上-面向对象分析与设计
问题1：
问题2：
问题3：
回答1：
A1=房产经纪 A2=系统管理员
U1=删除房产信息 U2=修改房产信息 U3=审核售出和停售的房产信息
# U1=审批授权 U3=删除房产信息
# U1内容在材料中并没有展示出来；
a=扩展关系 b=泛化关系
# 修改房产信息 a 导出房产信息
# 删除房产信息 b 归档
# a <<include>> b<<extend>>
问题2：
C1=Property C2=House C3=Cando
C4=User C5=Manager C3=Agent
问题3:
AgentList主要属性：姓名、家庭住址、联系电话、受雇的起止时间、 房产证明、房产的起始时间和终止时间；
# xhj分析：这里书写的内容是Agent的属性，而不是AgentList的属性；
# AgentList在Agent和Property中间，应该是联系两者的一个属性；
# AgentList主要属性：房产经纪负责该房产的起始时间和终止时间；
20上-算法-希尔排序
回答1：
k /= 2
k > 1
delta[i] >= 1 # data[k-dk] > data[k]
# 不清楚dk是什么 需要考虑清楚这个是什么东西。
data[j] = t # data[j+dk] = t
回答2：
小于 是 # 否
回答3：
7 9 15 -1 8 20 4
# 4 9 -1 8 20 7 15
20上-代码-中介者模式
回答：
public void buy(double money,WebService service);
# void buy(double money,WebService service);
WebServiceMediator
public void buyService(double money);
# abstract void buyService(double money);
this.buy(money,this);
# meditor.buy(money,this);
this.buy(money,this);
# meditor.buy(money,this);
10上
10上-结构化分析
回答1：
E1= 前端应用 E2= 数据管理员 E3= 后端数据库
回答2：
D1= 用户表 D2= 操作表 D3= 权限表
回答3：
P= 请求接收
输入流
输出流
# P= 操作结果处理
输入流： 操作结果 起点：E3 终点：P
输出流： 处理后的操作结果 起点：P 终点：E1
两个数据流：
起点：E3 终点：E1
起点：
# 起点：D2 终点：权限验证 起点：D3 终点：权限验证
回答4：
常见的绘制加工的输入、输出时可能遇到的问题：
1 输入输出不匹配，出现无中生有和有来无回的情况；
2 加工图形绘制错误；
3 数据流图整体缺失加工。
# 常见的绘制加工的输入、输出时可能遇到的问题：
只有输入而无输出 或者 黑洞
只有输出而无输入 或者 奇迹
输入的数据流无法通过加工产生输出流 或者 灰洞
输入的数据流与输出的数据流名称相同
10上-数据库分析
问题1：
问题1：
联系1 ： 课程 i 开设 j 班级
联系2 ： 实验 k 安排 g 学生
联系2 ： 实验 k 安排 l 实验员
注意：以后多的关系都采用* 处理
问题2; （斜体）
1 课程编号、课程名称、实验学时、开课班级； # 课程编号、班级号
2 实验名 # 实验室编号 课程编号
3 课程编号、实验编号、实验员编号 # 批次号、安排学期
4 实验编号 # 实验员编号 实验员姓名
5 学生编号、班级 # 学号、班级编号
6 实验名、学号、姓名、班级 # 实验编号、学号
问题3：
实体=授课教师，联系： 课程 i 授课 j 授课教师 多对多的关系
# 授课教师 连接开设这个联系，与课程之间的关系是：一对多关系。
回答2 补充：
10上-面向对象分析与设计-中介者
回答：
（1）
A1 = 乘客 A2 = 技术服务人员 U1 = 付款 # U1= 支付
（1）= <include> (2) = <include>
（2）
C1= 键盘 C2= 目的地键盘 C3= 车票键盘 C4= 继续/取消键盘
多重度是啥? # 表示该模块在整个系统中出现的次数。
# （3）~（6）都是1
(3)
中介模式内涵：
# 使用 Mediator模式，可以使各个对象间的耦合松散，只需关心和Mediator的关系，使多对多的关系变成了一对多的关系，可以降低系统的复杂性，提髙可修改扩展性。
10上-算法-有向图的拓扑排序
回答：
（1）
InitQueue（&Q）
DeQueue（&Q，&p） # DeQueue(&Q，&w)
inDegree[p->adjvex]
inDegree[p] # inDegree[p->adjvex]
# k<G.n 或 k!=G.n
回答2：
回答3：
10上-代码-策略设计模式
回答：
（1）FlyBehavior flyBehavior
(2)TakeOffBehavior takeOffBehavior
(3)flyBehavior.fly()
(4)takeOffBehavior.takeOff()
(5)extends
(6)SubSonicFly()
(7)VerticalTakeOff()
注意
当出现多个类实现同一个接口时，要注意后期创建对象时，使用的具体是哪个实现类。
10下
10下-结构化分析
回答：
(1)
E1= 客户 E2= 财务部门 E3= 仓库
（2）
D1= 客户文件 D2= 商品文件 D3= 订单文件
（3）
P1= 产生配送单 P2= 准备发货单
订单记录 D3→P1 配送单 P1→E3
订单记录 D3→P2 客户记录 D1→P2 发货单 P2→发货
缺少一条数据流：客户记录 D1→创建客户账单
10下-数据库分析
回答：
（1）
1=业主编号、房号 主键，外键=房号，业主编号#外键无
2=员工号、所属部门号 主键，外键=员工号，所属部门编号
3=部门号、部门负责人 主键，外键=部门号，部门负责人
4=收费类型、单位、单价 主键，外键=收费标准=收费类型，无外键
5=房号、业主编号、收费日期、数量 主键，外键=房号、收费日期，房号、业主编号 #主键房号、业主编号、收费日期 外键房号、员工号
（2）
a=* b=1 c=1 d=* e=* f=*
# b=* e=*
# 收费标准 收费 收费员 之间的联系是：*：*
（3）
#业主关系属于第2范式。当某业主有多套住房时，属性“业主编号，姓名，房屋面积，工作单位，联系电话”等信息在业主关系表中重复存储，存在数据冗余。
10下-面向对象分析与设计
回答：
1
C2 = 录入及提交处方 C5 = 验证处方
C1 = 注册 C3 = 填写顾客资料 C4 = 支付方式
（1）= 1 （2）=* （3） = 1 （4） =1 （5）=* （6）= *
# C1 付款方式 C2 处方 C3 信用卡 C4 支付宝账户 C5 处方上的药品
# （1）= 1 （2）=0..* （3） = 1 （4） =1..* （5）=0..* （6）= *
2
S1 = 审核中 S2 = 无法审核 S3 = 医生信息无效 S4 = 无效处方
（7）医生信息不正确 （8）提交处方 （9）医生信息不正确 （10）7天内未给出确认答案
# (8) 医生信息正确 （9）医生回复处方无效
3
分别表述融合和组合关系。
# 分别是组合和聚合。
# 组合关系中，整体对象与部分对象具有同一的生存周期。当整体对象不存在时部分对象也不存在。(1分)
# 而在聚合关系中，对整体对象与部分对象没有这样的要求。
10下-算法-堆排序
回答：
1
(1) A->int_array[0]
(2) A->int_array[0] = A->int_array[A->array_size-1]
(3) A->array_size # A->array_size-1
(4) A->int_array[PARENT(i)] < A->int_array[i] # A->int_array[PARENT(i)] < key
(5) A->int_array[i] = key
2
(6) O(1) (7) O(1) (8) O(n)
# (7) O(lgn) (8) O(lgn)
3
3个位置
10下-代码-组合模式
回答：
(1) abstrack # abstract class
(2) this.name
(3) Conmany
(4) Conmany
(5) super # children
(6) super # children
(7) root.Add(comp)
(8) comp.Add(comp1)
11上
11上-结构化分析
回答：
1
E1=设备 E2=护理人员 E3=医生
# E1=病人
2
D1=生命特征值信息 D2=日志文件 D3=病历文件 D4=治疗意见信息
# D1=生命特征范围文件 D4=治疗意见文件
3
重要生命特征 s=本地监控 e=格式化生命特征
病历文件 s=生成病历 e=D3
格式化后的生命特征 s=格式化生命特征 e=检查生命特征
# 生命特征 s=D2 e=生成病历
4
实体E1和E3存在数据流，在一些特殊情况下；
# 实体E1和E3不存在数据流。医生和护理人员根据查询到的治疗意见对病人进行治疗属于系统之外的行为，所以两个实体之间不可以有数据流。
11上-数据库分析
回答：
1
仓库 1 生成 * 采购订单
采购订单 * 包含 * 服装
服装 * 供应 * 供应商
仓库 * 存放 * 服装 √
# 采购 和 服装、采购订单、供应商 均属于*关系
2
（1）仓库编号、库管员 # （1）仓库编号、库管编号
（2）供应商编码、服装编码
（3）订单编码、订货日期、应到货日期
（4）服装编码、服装数量、采购价格、供应商编码 # 订单编号、服装编码、服装数量、采购价格、供应商编码
主键：
库管员：库管员编号
仓库信息：仓库编号
服装：服装编码
供应商：供应商编码
供货情况：供应商编码、服装编码
采购订单：订单编码
3
库管员 * 抽查 * 仓库
# 抽查 与 库管员、仓库、服装 均属于*关系
11上-面向对象分析与设计
回答：
1
U1=移动元素 U2=调整元素大小 （1）=extends （2）=extends
# （1）=extend （2）=extend
2
C1=选择工具 C2=创建工具 C3=线条工具 C4=矩形工具 C5=椭圆工具
C6=线条 C7=矩形 C8=椭圆
（3）0..1 (4)0..1 (5)1 (6)*
# (4)1
3
桥接模式的内涵是：
# 桥接模式将抽象部分与它的实现部分分离，使它们都可以独立地变化，对一个抽象的实现部分的修改应该对使用它的程序不产生影响。
11上-算法-自定义排序
回答：
1
（1）R
（2）c[a[i] + 1
(3) c[i]+c[i-1]
(4) a[i]
2
时间复杂度：O（n） 空间复杂度：O（n）
3
稳定。因为a数组中元素的读取到放入b数组中，都是按照顺序执行，即 5和 5*在a数组是前后关系，那么在b数组中也是前后关系，不会存在5*位于5之前的情况。
# 算法不稳定。算法不稳定的原因在于将数组a中元素放到数组b中时，是从数组a的第一个元素开始，依次取出元素放到数组b中。这样，相.同的两个元素值，在数组a中的相对位置和在数组b中的相对位置正好相反。若从数组a的最后一个元素开始，依次向前取元素放到b数组中，可以保持相同元素的相对位置。
修改第12行代码，为for(int i = n-1;i >= 0 ;i--)
11上-代码-组合模式
回答：
(1) abstract class
(2) public abstract void add(MenuComponent menuComponent)
(3) add() # add(menuComponent)
(4) menuComponent.print()
(5) allMent.print()
11下
11下-结构化分析
1
E1=受聘者 E2=部门经理 E3=工资系统
2
D1=未录用的应聘者表 D2=评价结果表
3
P1=验证申请 P2=审查申请 P3=职位安排评价
# P1=验证信息
4
不平衡。
数据：录用职位 起点：P3 终点：E3
# 已受理的申请 起点：1.2受理申请
# 谢绝决策 起点：2.2谢绝决策
11下-数据库分析
1
员工* 归属 1部门
经理1 管理 1部门
业务员1 处理 *托管申请
客户1 提出 *托管申请
实体与子实体之间的关系，为：员工与经理、业务员之间的关系，之间的关系是包含关系。
2
11下-面向对象分析与设计
11下-算法
11下-代码
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
