UML:统一建模语言(Unfied Modeling Language)是描述、构造和文档化系统制品的可视化语言。
建模:给现实世界的事物建立被人所理解的模型。
UML是一个庞大的图形化表示法体系。(UML仅仅是一种图形表示法。)
应用UML的三种形式:草图、蓝图、编程语言
UML的要素:表示法(图形)、过程(UML与过程无关,但最好用于RUP)、工具(如StarUML、Ratinal Rose)
RUP:统一软件开发过程
1.面向对象分析与设计(OOA/D)
分析------对问题和需求的调查研究
设计------满足需求的概念上的解决方案(设计是对分析的一种细化)
面向对象分析-----在问题域内发现和描述对象
面向对象设计-----如何定义软件对象以及它们之间如何协作以实现需求
软件建模----动态模型(如何交互)与静态建模(都有哪些东西(对象))
分析与设计过程:定义用例->定义领域模型->定义交互图->定义设计类图
—>1.定义用例(用例是需求分析的一种工具,它是一些情节的描述)
—>2.定义领域模型(OOA)(识别问题中的概念,它是对真实世界领域中的概念和想象可视化,与具体实现的软件技术无关)
—>3.分配对象职责并绘制交互图(动态建模)。OOD关注的是软件对象的定义(职责与协作)
—>4.定义设计类图(静态建模)。 从领域模型以及交互图中获得启示,定义软件类,包括属性、方法等等
例子
分析与设计过程:定义用例->定义领域模型->定义交互图->定义设计类图
1.定义用例(用例是需求分析的一种工具,它是一些情节的描述)
------1)游戏者请求骰子
------2)系统展示结果:如果投资总点数是7,则赢,否则游戏者输
2.定义领域模型(OOA)(识别问题中的概念,它是对真实世界领域中的概念和想象可视化,与具体实现的软件技术无关)
-----1)游戏者
-----2)骰子
-----3)骰子游戏
3分配对象职责并绘制交互图(动态建模)
OOD关注的是软件对象的定义(职责与协作)
4.定义设计类图(静态建模)
从领域模型以及交互图中获得启示,定义软件类,包括属性、方法等等
2.UP(统一软件开发过程)与瀑布模型
软件开发过程描述了构造、部署以及维护软件的方式。
统一过程是一种流行的面向对象系统的迭代软件开发过程。特别是RUP(Rational统一过程)是对统一过程的详细精华。
瀑布生命周期试图在编程之前(详细)定义所有或大部分需求、创建出完整的设计、定义“可靠的”计划或时间表。
3.UML概述
UML包括:事物、关系、图、扩展机制
1.事物
–>结构:类、接口、构建、节点等等
–>行为:交互(消息)、状态等等
–>分组:包、子系统等等
–>注释
2.关系:依赖、关联(聚合、组合)、泛化(继承)、实现(实现接口)
3.图:用例图、交互图(顺序图、协作图)、类图、活动图、状态图等等
4.扩展机制(在特定环境下起作用):约束等
图的分类:静态建模与动态建模
1.静态建模:类图
2.动态建模:顺序图(协作图)、用例图、活动图、状态图
类图实例
用例图实例
状态图实例
活动图实例
用例试图:需求分析阶段
逻辑视图:设计姐u但,用例的实现
组件(构建)视图:构建表示封装了起内容的系统模块:构建是相对独立的模块
部署视图:表示软件元素在物理架构上的部署,以及屋里元素之间的通信
4.类图
类图允许我们去标记静态内容及类之间的关系
1.类的基本表示法:名称、属性(类型,可见性)、方法(参数,返回值)
2.接口的基本表示法:圆形表示法、构造性表示法
3.包:用来表示层次结构(子系统)、组织各种内容
4.关系:依赖、关联、泛化、实现
–>依赖:一个事物的变化影响另外一个事物(依赖其实就是耦合)
低耦合:表示要降低跟不稳定的其他对象之间的依赖关系
–>关联(在某个时间两个对象之间由一定联系):关联名、导航、角色、多重性、聚合、组合
关联名:给关联取一个名称
导航:是否可以从一个对象访问到另外一个对象
角色
多重性:对象和对象之间的关系(多对一,一对多,多对多等)
聚合:整体与部分的之间关系。如下:
组合:强聚合,整体与部分的生命周期相同。如下:
–>泛化:extends(继承)
–>实现:implements
5.领域模型
领域模型是OO(面向对象)分析中最重要和经典的模型。
领域模型(domain model),也称为概念模型、领域对象模型、分析对象模型。在对项目进行分析的时候,往往会创建相应的领域模型。
领域模型包括:概念(名称),关联,属性
领域模型是现实世界与软件实现之间的过度。
如何创建领域模型:通过名词短语、分析模式寻找概念类;创建类图;添加关联和属性
属性的表示法:普通数据类型表示为属性;复杂的领域概念不应建模为属性
类图例子
分析:
1.对象有神州六号飞船、神州飞船、轨道舱、返回舱、推进舱、逃逸求生塔、航天员、太阳能电池翼
2.由此可看出神州六号是神州飞船的泛化
3.由此可看出,轨道舱、返回舱、推进舱、逃逸求生塔和神州六号飞船是部分与整体的聚合关系
4.航天员依赖返回舱,返回舱有驾驶飞船功能
5.航天员依赖轨道舱,轨道舱有工作和休息功能
6.航天员依赖逃逸救生舱,逃逸救生舱有逃生功能
7.太阳能电池翼与神州六号飞船是部分与整体的聚合关系,且为多对一的关系,太阳能电池翼有提供天池功能
具体类图如下:
5.顺序图
顺序图是动态建模的一种
1.顺序图是交互图的一种(交互图还包括协作图)
2.顺序图是强调消息时间顺序的交互图(协作图则是接收和发送消息的对象的结构组织的交互图)
3.动态建模:随着时间的推移,一些对象被创建,属性值的改变,以及其中一些对象的销毁,对象之间的相互调用
4.顺序图元素:对象,对象生命线,消息(方法的调用),对象的创建与销毁
登录顺序图
添加用户例子
结合类图与顺序图给对象分配职责(例子)
1.分析需求,得出用例图(简单用例图)
2.分析概念模型
3.用例实现
6.协作图
协作图也是描述对象之间的交互。
协作图强调接收和发送消息的对象的结构组织。
顺序图用在设计的时候,协作图用在分析的时候。
7.用例图
需求分析与用例
1.需求:系统(或者说是项目)必须提供的能力和必须遵从的条件
2.需求分析的一种重要手段是确定和编写用例
3.用例定义:用例是文本形式情节描述,用于需求的发现和记录。用例会影响后续的OOA/D工作
4.参与者:某些具有行为的事物,可以是人(由角色标识)、计算机系统或组织
5.场景:参与者和系统之间的一系列特定的活动和交互(主成功场景和交替场景(或主路径和扩展路径))
–>主成功场景:如管理员向系统提交用户名和密码
–>交替场景:如如果用户名不对或密码不对等
6.用例就是一组相关的成功和失败场景集合
7.系统边界:参与者是在系统外部的具有行为的事物,在系统内部的不是参与者。
如:
–>将商店作为边界,则顾客是参与者(收银员不应作为参与者)
–>将商店管理软件作为边界,则收银员可以作为参与者
8.用例的目的与形式
–>用例:强调用户的目的和观点。(谁使用系统?它们使用的典型场景是什么?它们的目的是什么?)
–>用例编写形式:摘要(需求分析早期使用,通常用于成功场景);非正式(需求分析早期使用,可覆盖不同的场景);详述(详细编写所有步骤及各种变化)
–>用例的名称应使用动词开头
–>编写用例的名称应使用动词开头
–>编写用例的时候应尽量使用行业的专业名称,而不是计算机专业术语
用例编写格式
- 用例编写
- 用例名
- 用例描述
- 参与者
- 前置条件
- 后置条件
- 基本路径
- 1
- 2
- 3
- 扩展点
- 2_1
- 2_1_1
- 扩充说明
用例文档实例
9.用例编写基本规则(参与者动作与系统响应)
–>.参与者提交动作->系统产生动作->系统返回响应(参与者与系统之间的交互)
–>基本路径(主成功场景):只描述成功的场景,不能出现"如果…"等字眼,这些可放在扩展点中
–>基本路径一般在8步左右,不应超过10步
10.如何发现用例:1.选择系统边界; 2.确定参与者;3.确定每个主要参与者的目标;4.定义满足用户目标的用例,根据其目标对用例命名
基本思维方式
调研需求时最先弄清楚有多少部门,多少岗位(参与者),然后找到每一个岗位的业务代表,问他们类似的问题:你平时都做什么?(参与者目标) 这件事是谁交代办的?做完之后需要通知或传达给谁吗?做这件事你都需要填写什么表格吗?(用例)
用例图
1.用例彼此之间可能存在一些联系(但不应过分关注用例图的用例关联,应注重用例文本的书写)
–>包含关系:主要目的是避免用例文本的重复编写。如处理销售、处理租金等用例可包含处理信用卡支付用例
–>扩展关系:可以将可选路径中的场景抽象为扩展关系(通常是没有必要的)
–>泛化关系:两个或更多用例在行为、结构、目的等方面存在共性时,可使用泛化关系
思考题
参与者:原来的财务系统
参与者:使用管理系统的人员
参与者:顾客、会计系统
用例图例子
8.状态图
状态图:用来描述一个特定的对象所有可能的状态,以及由于各种事件的发生引起的状态之间的转移和变化。
一卡通的状态变化
高级应用(历史状态)
9.活动图
活动时UML动态视图之一,用来描述事物或对象的活动变化流程。
1.活动:活动(Action)是活动图主要节点,分为简单活动和复合活动
–>简单活动:不能再分解的活动
–>复合活动:可以再分解的活动
2.活动流:描述活动之间的又向关系,反映一个活动向另外一个活动之间的转移,用带箭头的实线表示
3.分支:表示活动流的分叉和合并,表示从一个活动按照某种条件转移到几个不同的活动
4.分劈和汇合:表示并发的同步行为,用同步杆表示
5.泳道(swimlane):是活动图中的区域划分,每一个泳道代表一个责任区域,一个泳道中包括一组相关活动
6.对象流:反映活动与对象之间的依赖关系,表示对象对活动的作用或活动对对象的影响,用依赖关系表示
案例
10.构件图
构件是一个相对独立的可装配的物理块,一般作为一个独立的文件存在
构件具有稳定的接口,相互之间可以调用,构件之间存在依赖关系
11.部署图
部署图是用来描述系统中计算结点的拓扑结构和通信路径与结点上运行的软件结构
12.GRASP:基于职责设计对象
通用职责分配软件模式
1.创建者:谁应该负责创建某类的实例?
2.信息专家:给对象分配职责的基本原则是什么?
3.低耦合:怎样降低依赖性,减少变化带来的影响,提高重用性?
4.控制器:再UI层上首先接收和协调(控制)系统操作的第一个对象是什么?
5.高内聚:怎样保持对象是有重点的、可理解的、可管理的、并且能够支持低耦合?
6.多态:如何处理基于类型的选择?如何创建可插拔的软件构件?
7.纯虚构:当你并不想违背高内聚低耦合,但基于专家模式所提供的方案又不合适时,哪些对象应该承担这一职责?
8.间接性:为了避免两个或多个事物之间耦合,应该如何分配职责?如何使对象解耦合,以支持低耦合并提高复用性潜力?
9.防止变异:如何设计对象,子系统和系统,使其内部的变化或不稳定不会对其他元素产生不良影响?