Thinking In UML学习笔记一

一.Modeling:建模
通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解,同时把这种理解概念化,将这些逻辑概念组织起来,构成一种对所观察的对象的内部结构和工作原理的便于理解的表达.
首先要确定抽象的角度



人(actor),事(use case),物(entity),规则

二. 版型stereotype
三.参与者actor,主角
在系统之外与系统交互的某人或某事物.关键点: 系统之外(系统内部的人或物都不是参与者,而是business worker)



关键点: 边界如何确定

谁对系统有明确的目标和要求并主动发出动作?
系统是为谁服务的?
目标和结果是在边界内出现

业务主角:参与者的一个版型,是与业务系统有交互的人和事物,用来确定业务范围.(针对业务人员而非计算机用户)

用例Use Case
用例定义了一组用例实例.其中每个实例都是系统所执行的一系列操作,这些操作生成特定主角可以观测的值
(与参与者交互的,并给参与者提供可观测的有意义的结果的一系列活动的集合.)
参与者,前置条件,场景,后置条件



用例的特征:

相对独立
执行结果对参与者来说是可观测的和有意义的
由参与者发起
以动宾短语命名

一个用例就是一个需求单元,分析单元,设计单元,开发单元,测试单元,甚至部署单元

业务用例 Business Use Case: 用例版型的一种,用于描述客户现有业务
业务用例实现/实例 Business Use Case Realization: 描述业务用例的一种实现方式

业务实体
类(class)的一种版型.具有属性和方法
代表业务角色执行业务用例时所处理或使用的生物.一个业务实体经常代表某个对多个业务用例或用例实例有价值的事物.一般而言,一个好的业务实体不包含关于其使用主体和使用方法的信息.

包package

容器,将信息分类
依赖关系: 如果A变化,B必然也变化,则B依赖于A
高内聚,低耦合

常用版型

领域包(domain package):用于分类业务领域的业务单元,每个包代表一个业务领域;
子系统(Subsystem)
组织结构(Organization unit)
层(Layer)分类软件层次

分析类
用于获取系统中主要的"职责簇",代表系统的原型类,是系统必须处理的主要抽象概念的第一个关口.如果希望获得系统的高级概念性简述,则可对分析类本身进行维护.分析类还可产生系统设计的主要抽象-系统的设计类和子系统
包括:边界类boundary,控制类control,实体类entity

边界类:用于对系统外部环境与其内部运作之间的交互进行建模的类.这种交互包括转换事件,并记录系统表示方式(例如接口)中的变更.
控制类:对一个或几个用例所特有的控制行为进行建模,来源于对用例场景中行为(动词)的分析和定义.
实体类:用于对必须存储的信息和相关行为建模的类.源自业务模型中的业务实体.

关系

关联关系association:实线(带或不带箭头),表示一个对象了解其他对象
依赖关系dependency:带箭头的虚线,描述一个对象的修改会导致另一个对象的修改.(与关联不同,依赖除了了解外,还会使用其他对象的属性或方法--依赖是特殊的关联)
扩展关系(extends):表示可选,而不是必需(即使没有扩展用例,基本用例也是完整的)
包含关系(include):特别用于用例模型说明在基本模型中插入的行为段
实现关系(realize):在用例模型中连接用例和用例实现,说明基本用例的一个实现方式


实现关系
精化关系(refine)一个基本用例可以分解出许多更小的关键精化用例,更细致地展示了基本用例的核心业务;仅用于建模阶段,这些子对象并没有增加,减少改变基本对象的行为和属性,仅仅是更加细致和明确化了


精化关系
泛化关系(generalization)表示一个类对另一个类的继承
聚合关系(aggregation)用于类图表达整体由部分构成的语义.整体和部分不是强依赖的
组合关系(composition)用于类图表示整体拥有部分的语义,强依赖