软件建模与设计
一、面向对象和UML
控制软件复杂性的基本方法:分解、抽象、模块化、封装
1. 面向对象
1.1 定义
面向对象=对象+类+继承+通信
1.2 特性
面向对象的特性:标识、分类、继承、多态
- 标识
? 识别系统中的对象(Object)
- 分类
? 拥有相同数据结构(属性)和行为(操作)的对象被组成一个类(Class)
- 继承
? 在用层次关系组织的类中共享属性(attribute)和操作(operation)
- 多态
? 对于不同的类来说,相同的操作会产生不同的动作
1.3 优点
开发的系统比较稳定、易于理解、可靠性好、适应性好(适应需求的变化,利于构建大型系统)
- 适应性(以java接口为例)
? 原本:每多一种类型就要多写一个方法
- 可靠性(以包为例)
? 把要一起使用的方法放在同一个包里,使用时不会少用方法,这些方法也不会别乱使用
1.4 开发模型
瀑布模型、迭代模型
2. UML
UML的特点:统一的标准、面向对象、可视化、独立于过程、概念明确
二、类建模
1. 对象和类的UML表示法
2. 链接和关联的UML表示法
3.2 关联端名
3.4 关联类
关联关系之间衍生出的类。多对多必须使用。
3.5 限定关联
加一个限定符降低多重性。本
来一个bank有很多个account,加了个id后要么有要么没有。
二、高级类建模
1. 枚举
不要用泛化
3. 可见性
公用可见性(+)
私有可见性(-)
保护可见性(#)
包可见性(~)
6. 组合
生命周期相同,是特殊的聚合。如果circle不在了,point也不在了
9. 多重继承解决方案
产生二义性。不知道用哪一个方法。
使用委派(组合),用多个部件替换多个继承
将LandOperation和WaterOperation作为Vehicle的抽象方法
9.2 继承和委派
将Employee分出一部分职责分给另一个类,自己只负责原来一部分功能,本质还是委派(组合+继承)
关联是非偶然性、长期性的、比较强的(代码中被关联类以属性存在于关联类中)
3.1 嵌套状态
子状态
4. 类模型和状态模型的关系
状态模型详细描述了类模型中对象所允许的变化序列。
状态图描述了某个给定类的对象的全部或部分行为。
四、交互建模
1. 什么是交互模型
交互模型描述对象要如何交互才能产生有用的结果
交互模型描述多个对象的整体行为
2. 交互模型的类型与作用
用例模型,顺序模型,活动模型
3.4 用例的三种关系
包含、扩展、泛化
- 包含(include)
-
泛化(generalization)
4.3 建立顺序模型的准则
至少为每个用例编写一种场景。
把场景抽象成顺序图。
划分复杂的交互。
为每种错误条件绘制一张顺序图。
5. 活动模型
5.1 活动、动作状态、活动状态、泳道
- 活动
表示某流程中的任务的执行,可以表示某算法过程中语句的执行。
- 动作状态
是原子的,不能被分解,没有内部转移,没有内部活动。
动作状态的工作所占用的时间是可忽略的。
可被视作活动状态的特例
- 活动状态
不是原子的,可分解。
活动状态的工作的完成需要一定的时间。
- 泳道
是活动图中的区域划分
根据每个活动的职责对所有活动进行划分,每个泳道代表一个责任区
一个泳道可能由一个或多个类来实现
5.2 活动图及画法
5.3 活动图与顺序图的区别
顺序图强调的是从对象到对象之间的控制流。
活动图强调的是从步骤(活动)到步骤的控制流。
五、软件系统分析
1. 软件开发阶段
-
系统构思
构思并描述临时性需求
-
分析
通过构造模型深入理解需求
a) 领域分析
b)应用分析
-
系统设计
设计系统架构
-
类设计
设置真实模型及算法
-
实现
-
测试
-
培训
-
部署
-
维护
2. 软件开发生命周期
2.1 瀑布开发
适用于需求非常明确的应用。
完全的瀑布式开发极少。
通常在高版本 的软件开发中才可能出现。
2.2 迭代开发
多数软件开发的首选方式。
灵活,及时响应变化。
开发风险小。
3. 问题陈述
3.1 目标
描述待构建的系统的目标
提出构建系统的总体方案
3.2 注意
区分:需求、设计和实现。
描述要做什么,而不是怎么做。
该阶段的概念文档可包含一个实现示例。
问题陈述本身可能不完整,甚至错误。
4. 系统分析
4.1 模型描述对象的三个方面
-
类模型——描述对象的静态结构
-
交互模型——描述对象之间的交互
-
状态模型——描述对象的生存期
4.2 两个阶段
-
领域分析:分析问题的本质
-
应用分析:从应用的角度分析
5. 领域分析
构造领域类模型步骤:
-
寻找类
-
准备数据字典
-
寻找关联
-
寻找对象和链接的属性
-
使用继承组织和简化类
-
验证可能查询的访问路径
-
迭代并细化模型
-
重新考虑类的抽象层次
-
把类组织成包
六、应用分析
补充类模型和状态模型。
1. 应用的交互模型
-
确定系统边界
-
构建用例模型
? – 识别参与者
? – 识别用例
-
构建场景和顺序图
-
构建复杂用例的活动图
-
检查用例和类模型
2. 应用的类模型
界定了应用程序本身,面向计算机
步骤:
- 用户界面
- 定义边界类(负责资源通信,还有实体类,控制类)
- 确定控制器 Controller
- 检查交互模型(是否满足交互行为)
3. 应用状态模型
- 用多个状态来确定应用类。
- 使用交互模型来寻找类的事件。
- 用状态图为每个类组织许可的事件序列。
- 检查状态图,确保公共事件的匹配。
- 用类和交互模型检查状态图,确保一致。
七、软件系统设计
确定系统整体结构和风格,设计解决方法
1. 系统设计(总体设计)
1. 估算系统性能
只需要做大致的估算
目的是确定软件系统是否可行
2 制定复用计划
可复用的事物:类库,模型,框架,模式
1.3 划分子系统
水平分层,垂直分区
1.4 确定并发性
判断并发:不交互的情况下,可以同一时间发生。
1.5 分配子系统硬件
1.6 管理数据存储
1.7 处理全局资源
1.8 选择软件控制策略
1.9 处理边界条件
解决系统以下问题:初始化,终止,失效
1.10 权衡优先级
1.11 架构风格
常见架构风格:
-
批处理转换,不与外部发生交互,编译器
-
连续性转换,依赖输入更新来更新输出,是一个增量计算,GUI的放大。
-
交互式界面,各种查询系统
-
动态仿真,分子运动建模。
-
实时系统,时间要求严格,通信设备。
-
事务管理器,订票系统。
2. 详细设计(类设计)
把分析阶段得到的类代入设计阶段,在类设计阶段细化对其进行细化。
2.1 填补需求间的鸿沟
功能和可用资源
2.2 用操作实现用例
2.3 定义操作的算法
成本最低,合适的数据结构
2.4 向下递归
按功能、机制递归
按功能、机制分层(MVC)
2.5 重构模型
2.6 优化数据访问路径
2.7 实现具体的行为
2.8 调整类结构
2.9 组织类和关联
3. 抽象类和接口
4. 理解面向对象的基本设计原则
4.1 开闭原则(最重要的原则)
在扩展性方面开发,在更改性方面封闭
使用接口、抽象机制、多态
4.2 Liskov替换原则
子类必须能够替换掉它们的基(父)类型,否则继承关系就是不正确的。
4.3 依赖倒置原则
依赖关系应尽量依赖接口(或抽象类),而不是依赖具体类。即依赖抽象而不是具体。
4.4 接口分离原则
使用多个专门的接口比使用单一的通用接口要好
将一个大接口分成几个小接口
八、软件系统实现
1. 实现建模
主要步骤:微调类、微调泛化关系、实现关联、准备好测试
1.1 微调类
拆分、合并类
拆分、合并属性
1.2 微调泛化关系
增加、删除
1.3 实现关联
单向关联、双向关联
用关联类实现关联(最常用)
1.4 准备好测试
单元测试、集成测试、系统测试
2. 数据库建模
主要步骤:实现类、实现关联、实现泛化、实线标识
2.1 实现类
类映射表,属性映射列
可以增加列,表示对象标识符和关联
2.2 实现关联
多对多——用一张表来实现
一对多——在多方添加外键
一对一——任意方添加外键
2.3 实现泛化
每个父类和子类都有一张表
每张表有含义相同的主键
2.4 实现标识
对象标识:每个表添加一个ID作为主键(推荐)
本设计原则
4.1 开闭原则(最重要的原则)
在扩展性方面开发,在更改性方面封闭
使用接口、抽象机制、多态
4.2 Liskov替换原则
子类必须能够替换掉它们的基(父)类型,否则继承关系就是不正确的。
4.3 依赖倒置原则
依赖关系应尽量依赖接口(或抽象类),而不是依赖具体类。即依赖抽象而不是具体。
4.4 接口分离原则
使用多个专门的接口比使用单一的通用接口要好
将一个大接口分成几个小接口
八、软件系统实现
1. 实现建模
主要步骤:微调类、微调泛化关系、实现关联、准备好测试
1.1 微调类
拆分、合并类
拆分、合并属性
1.2 微调泛化关系
增加、删除
1.3 实现关联
单向关联、双向关联
用关联类实现关联(最常用)
1.4 准备好测试
单元测试、集成测试、系统测试
2. 数据库建模
主要步骤:实现类、实现关联、实现泛化、实线标识
2.1 实现类
类映射表,属性映射列
可以增加列,表示对象标识符和关联
2.2 实现关联
多对多——用一张表来实现
一对多——在多方添加外键
一对一——任意方添加外键
2.3 实现泛化
每个父类和子类都有一张表
每张表有含义相同的主键
2.4 实现标识
对象标识:每个表添加一个ID作为主键(推荐)
值的标识:使用值得组合
文章知识点与官方知识档案匹配,可进一步学习相关知识Java技能树首页概览91673 人正在系统学习中
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!