UML——1
1. 2-8原则用例
2. 瀑布模型质量文档、管理文档、设计文档(类比为水)
3. 模型:UML
4. RUP的软件开发周期:反复、迭代、循序渐进
5. UML体系结构视图:五个视角
6. UML 2.0:九个图用例图:最核心
7. 活动图、状态图
UML——2
1. 学习网站:http://www.umlchina.com/
2. 由外向内,逐步求精(精:程序员可以理解)
3. 软件需求:非功能需求、功能需求、设计约束
4. 角色:执行者(Actor):在系统之外,透过系统边界与系统进行有意义交互的任何事物(人/物)
5. 角色、分类
6. 主执行者完成用例时可能需要辅助执行者
a) 发起者:左边
b) 被动者:右边
7. RUP用例实例是在系统中执行的一系列动作(步骤),这些动作将生成特定执行者可见的价值结果(目标),一个用例定义一组用例实例(路径)。
8. 识别用例
a) 业务语言而非技术语言
b) 用户观点而非系统观点
9. 用例命名:加上角色、动宾构成一句完整的话
a) 用户执行者视角
b) 状语动宾
c) 不用弱动词、弱名词
10. 角色直接一级用例无包含、继承不做登录
11. 把步骤作为一个用例——错误
a) 把一件事而不做其他事:一个用例(无必然关系)
b) 一级用例——独立性
c) 完成某一件事必需做其他事——步骤(有必然,因果关系)
12. 二级用例必需是一级用例的步骤,一级用例完成结果
13. 用例关系
a) <>包含
b) <>扩展
c) 泛化
14. 二级用例要求是
a) 一级用例的一个步骤或几个步骤
b) 某种设备某种功能具有设备独立性、功能独立性、位置独立性的一个功能
c) 程序员可理解
15. 泛化:可相互替代(兄弟)基本上用不到
16. 真一级和假一级的关系:对真一级归类总结如:管理好友
a) 假一级:虚拟,无价值,二级才有真实价值
17. 一级
a) 左、中、右(类比菜单栏) 二级:包含放在最上面反映顺序
18. 化繁为简
a) 重用——设计师责任
b) 找到相同的地方
UML——3
1. 用例——菜单关系
2. 7±2:记忆原则,归类
3. 步骤
a) 识别系统边界和执行者
b) 识别用例
c) 书写用例文档
d) 识别用例的关系
e) 用例的排序与分包
4. 粒度:功能的多少指令的多少
5. 协作者、参与者 +执行者(角色)
6. 用例文档
a) 前置条件:系统能不能成功,是否有必备的条件的数据
b) 后置条件:事做完后,系统保留的数据,拥有存储系统能检测到的需要保留的数据
c) 涉众利益:牵涉到的公司利益,受系统影响的人
d) 基本路径:没有遇到任何意外该怎么做
e) 扩展路径:基本路径发生意外该怎么做
f) 字段列表:涉及到的数据、交互的信息
g) 非功能需求:安全、可靠、性能参数指标
h) 设计约束:行业规定、法律、法规
i) 业务规则:界面设计等等
j) 待解决问题:有疑惑的地方
7. 用例交互四步曲:动作、验证、改变、回应(不要写失败最多不超过17步)
8. 交互
只书写可观测的、主动语句,句子必须以执行者或系统作为主语。每一句都要朝目标迈进分组和循环不要涉及界面细节
9. 预案提示写在意外上
UML——4
1. 处处看到细节(面临的问题)——战胜不了程序情怀
2. 当一级用例不只有一个二级用例且二级用例没有共享(指没有其他的父亲),则这个二级用例(儿子)、一级用例(父亲)合二为一
3. 过于强调细节,会把重要的问题掩盖
4. 点击:不涉及,不用那么细
5. 错误原因
UML——5
1. 抽象:视角、范围
2. U-C原则:数据 Use Create
3. 抽象:最少承诺,最少惊奇
4. 面向接口的程序设计
a) 用到------------>实现------------>接口
b) 假设、契约(功能还没实现,肯定用到)------------>接口
5. 编程契约模型协议
6. 封装:降低复杂性,隐藏细节
7. 面向对象:行为包裹数据
8. 高内聚、低耦合
9. Diagram Painter、StartUML
10. OOA OOD
11. 类图
12. 符号
a) public:+
b) private:-
c) protected:#
d) static:下划线_
13. 约束(写在花括号里)职责
14. 抽象类 <>
15. 接口 <>造型
16. 关联类模板类(<>)
17. 主动类嵌套类
18. 关系:依赖、泛化、实现
UML——6
1. 关系:依赖、泛化、关联实现
2. 类(术语)-------------->需求(业务)-------------->初步类图
3. 类图组成元素:类、接口、约束、关系、包
4. 约束:局部属性名第一个字母小写
5. 属性的可见性一般都是private-------------->符合封装思想
6. 行为(操作)最好为public
7. 类的职责:承担的责任和义务
8. 类的约束:一/多规则花括号
9. 类的种类:抽象类、接口、关联类、模板类、主动类、嵌套类
10. 多对多的关系:关系(关联类)本身就是一张表(ER模型)
11. 依赖关系:使用抽象授权绑定
12. 使用依赖
13. 关联的属性:名称、角色、多重性、导航性、限定符
14. 具体做某件事情:对象流程图:角色
15. 信息关联:具体-------------->抽象
16. Enterprise Architect-------------->EA UML Rose StartUML
17. UML和EA(百度文库)
18. 候选类
UML——7
1. 包图——组织文件封装性
2. 包:逻辑性物理性
3. 包图:描述包及其关系的图
4. 关系:依赖、泛化规范:一个元素只能属于一个包
5. 每一个包:独立的命名空间
6. 包的可见性:
a) +:public
b) #:protected
c) -:private
7. 包的构造型(五种):
a) <>
b) <>
c) <>
d) <>
e) <>
8. 依赖关系(四种):
a) <默认提供者------------>客户------------><
b) <>:简单名
c) <>:路径名。不合并包
d) <>:发展历史
9. 泛化关系:抽象包/实现包
a) Java:继承
b) 《UML用户手册》
c) 《UML精粹》
10. 阅读包
11. 创建包图:最小化系统间的耦合关系
a) 三个步骤:寻找包
12. 用例图:三类造型:边界类、控制类、实体类
13. 良好包:包内高内聚包间低耦合
14. 建模:对成组元素建模,对体系结构建模(MVC)
15. 用例图
a) 需求分析---------->不是在做设计
b) 《用例通过背景环境获取分析》:需求是利用计算机程序设计计算机能够在舞台领域里发挥出的作用
c) 用户说出什么功能---------->期望
i. 与系统应该怎样运行有关,而不是与需要完成什么有关的一切都是设计。设计不应成为需求的一部分,如果一条需求不能为应用程序设计做出贡献,那就说明需求太模糊,模糊的需求没有作用
ii. 需求必须永远使用用户的语言
iii. 每个目标必须清晰地与业务人员相关联
d) 软件要做就要做得最好
e) 软件就是一种契约人---------->软件<----------机器
f) CM PM CIM
g) 用例图:功能
h) RUP XP FDD
i. FDD---------->Feature描述技术---------->、、