软件工程考前抱佛脚学渣整理版.docx
- 文档编号:6137969
- 上传时间:2023-01-04
- 格式:DOCX
- 页数:10
- 大小:587KB
软件工程考前抱佛脚学渣整理版.docx
《软件工程考前抱佛脚学渣整理版.docx》由会员分享,可在线阅读,更多相关《软件工程考前抱佛脚学渣整理版.docx(10页珍藏版)》请在冰豆网上搜索。
软件工程考前抱佛脚学渣整理版
特别鸣谢国软12级-软5-铁宇彤
会画图
1、时序图(来源XX)
1、确定交互过程的上下文;
2、识别参与过程的交互对象;
3、为每个对象设置生命线;
4、从初始消息开始,依次画出随后消息;
5、考虑消息的嵌套,标示消息发生时的时间点,则采用FOC(focusofcontrol);
6、说明时间约束的地点。
下图是时序图的一个例子。
2、类图
在UML类图中,常见的有以下几种关系:
泛化(Generalization), 实现(Realization),关联(Association),聚合(Aggregation),组合(Composition),依赖(Dependency)
1.泛化(Generalization)
【泛化关系】:
是一种继承关系,它指定了子类如何特化父类的所有特征和行为例如:
老虎是动物的一种。
【箭头指向】:
带三角箭头的实线,箭头指向父类
2.实现(Realization)
【实现关系】:
是一种类与接口的关系,表示类是接口所有特征和行为的实现 【箭头指向】:
带三角箭头的虚线,箭头指向接口
3.关联(Association)
【关联关系】:
是一种拥有的关系,它使一个类知道另一个类的属性和方法;如:
老师与学生,丈夫与妻子
关联可以是双向的,也可以是单向的。
双向的关联可以有两个箭头或者没有箭头,单向的关联有一个箭头。
【代码体现】:
成员变量
【箭头及指向】:
带普通箭头的实心线,指向被拥有者
上图中,老师与学生是双向关联,老师有多名学生,学生也可能有多名老师。
但学生与某课程间的关系为单向关联,一名学生可能要上多门课程,课程是个抽象的东西他不拥有学生。
上图为自身关联:
4. 聚合(Aggregation)
【聚合关系】:
是整体与部分的关系.如车和轮胎是整体和部分的关系.
聚合关系是关联关系的一种,是强的关联关系;关联和聚合在语法上无法区分,必须考察具体的逻辑关系。
【代码体现】:
成员变量
【箭头及指向】:
带空心菱形的实心线,菱形指向整体
5. 组合(Composition)
【组合关系】:
是整体与部分的关系.,没有公司就不存在部门 组合关系是关联关系的一种,是比聚合关系还要强的关系,它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期 【代码体现】:
成员变量
【箭头及指向】:
带实心菱形的实线,菱形指向整体
6. 依赖(Dependency)
【依赖关系】:
是一种使用的关系,所以要尽量不使用双向的互相依赖。
【代码表现】:
局部变量、方法的参数或者对静态方法的调用 【箭头及指向】:
带箭头的虚线,指向被使用者
各种关系的强弱顺序:
泛化= 实现> 组合> 聚合> 关联> 依赖
下面这张UML图,比较形象地展示了各种类图关系:
3、用例图
1、包含(include)
包含关系:
使用包含(Inclusion)用例来封装一组跨越多个用例的相似动作(行为片断),以便多个基(Base)用例复用。
基用例控制与包含用例的关系,以及被包含用例的事件流是否会插入到基用例的事件流中。
基用例可以依赖包含用例执行的结果,但是双方都不能访问对方的属性。
包含关系对典型的应用就是复用,也就是定义中说的情景。
但是有时当某用例的事件流过于复杂时,为了简化用例的描述,我们也可以把某一段事件流抽象成为一个被包含的用例;相反,用例划分太细时,也可以抽象出一个基用例,来包含这些细颗粒的用例。
这种情况类似于在过程设计语言中,将程序的某一段算法封装成一个子过程,然后再从主程序中调用这一子过程。
例如:
业务中,总是存在着维护某某信息的功能,如果将它作为一个用例,那新建、编辑以及修改都要在用例详述中描述,过于复杂;如果分成新建用例、编辑用例和删除用例,则划分太细。
这时包含关系可以用来理清关系。
2、扩展(extend)
扩展关系:
将基用例中一段相对独立并且可选的动作,用扩展(Extension)用例加以封装,再让它从基用例中声明的扩展点(ExtensionPoint)上进行扩展,从而使基用例行为更简练和目标更集中。
扩展用例为基用例添加新的行为。
扩展用例可以访问基用例的属性,因此它能根据基用例中扩展点的当前状态来判断是否执行自己。
但是扩展用例对基用例不可见。
对于一个扩展用例,可以在基用例上有几个扩展点。
例如,系统中允许用户对查询的结果进行导出、打印。
对于查询而言,能不能导出、打印查询都是一样的,导出、打印是不可见的。
导入、打印和查询相对独立,而且为查询添加了新行为。
因此可以采用扩展关系来描述:
4、泛化(generalization)
泛化关系:
子用例和父用例相似,但表现出更特别的行为;子用例将继承父用例的所有结构、行为和关系。
子用例可以使用父用例的一段行为,也可以重载它。
父用例通常是抽象的。
在实际应用中很少使用泛化关系,子用例中的特殊行为都可以作为父用例中的备选流存在。
例如,业务中可能存在许多需要部门领导审批的事情,但是领导审批的流程是很相似的,这时可以做成泛化关系表示:
上面是我参考的一篇文章,觉得将三种关系的区别讲得很清晰,在此基础上结合自己的系统,对项目(在线购物系统)的用例做了整体的描绘。
*****************************************************************
(1)系统整体用例图
(商品用例图)
(购买信息用例)
(用户资料用例)
4、数据流图(DFD)
(见PPT)
5、数据流图转化为结构图(StructureChat)
(见PPT)
生命周期
生命周期模型的比较
生命周期模型
长处
短处
编码-修补生命周期模型
适用于不需要任何维护的小程序
总的来说不适合重要的程序
瀑布生命周期模型
纪律性强制的方法,文档驱动
交付的产品可能不符合客户的要求
快速原型开发生命周期模型
确保交付的产品符合客户的要求
还没有证明无懈可击
螺旋生命周期模型
风险驱动
只能用于大型的内部软件产品,开发者必须精通风险分析和风险排除
进化树模型
与现实世界软件开发最接近的模型,与迭代-递增模型等价
迭代-递增生命周期模型
与现实世界软件开发最接近的模型,蕴涵统一过程方法
开源生命周期模型
少量实例中工作相当好
实用性有限,通常不太起作用
敏捷过程
客户的需求模糊时能很好地工作
似乎只适合小规模项目
同步-稳定生命周期模型
能满足未来用户的要求,确保各组件能够成功集成
除了在Microsoft公司,还没有广泛地应用
测试
见PPT
设计原则
(不知道怎么考,直接附上PPT)
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件工程 考前 抱佛脚 整理