授课人


 4+1视图模型

 

什么是4+1试图模型?下图就是4+1视图表达方式

from clipboard

1  用例视图

用例视图是从外部用户的角度捕获系统,子系统或类的行为。 它将系统功能划分为对活动者具有意义的事务。这些功能片被称为用例。用例通过系统与一个或多个活动者之间的一系列消息描述了与活动者的交互。术语活动者包括人员、其他的计算机系统和进程。

2  设计视图

设计视图是由分析部分(用例视图)发展而来,是将需求转化为代码的前提,泛设计视图包括了类图(ClassDiagram)和状态图(statecharts),设计模型总结了交互图(interactiondiagram)中的对象和对象之间的关联,给出了目标系统的详细描述。设计模型主要包括类图和状态图。

3  实现视图

开发视图也称为模块视图,在UML中被称为实现视图,它主要侧重于软件模块的组织和管理。开发视图要考虑软件内部的需求,例如,软件开发的容易性、软件复用和软件的通用性,要充分考虑由于具体开发工具的不同而带来的局限性。开发视图通过系统I/O关系的模型图和子系统图来描述。

4  进程视图

进程视图侧重于系统的运行特性,主要关注一些非功能性需求,例如,系统的性能和可用性等。进程视图强调并发性、分布性、系统集成性和容错能力,以及逻辑视图中的功能抽象如何适合进程结构等,它也定义了逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。进程视图可以描述成多层抽象,每个级别分别关注不同的方面。
5 部署视图

物理视图在UML中被称为部署视图,它主要考虑如何把软件映射到硬件上,它通常要考虑到解决系统拓扑结构、系统安装和通信等问题。当软件运行于不同的物理节点上时,各视图中的构件都直接或间接地对应于系统的不同节点上。因此,从软件到节点的映射要有较高的灵活性,当环境改变时,对系统其他视图的影响最小化。

UML2的图形

1 用例图

用例图是指由参与者(Actor)、用例(Use Case),边界以及它们之间的关系构成的用于描述系统功能的视图。用例图(User Case)是外部用户(被称为参与者)所能观察到的系统功能的模型图。用例图是系统的蓝图。用例图呈现了一些参与者,一些用例,以及它们之间的关系,主要用于对系统、子系统或类的功能行为进行建模。


构成

用例图由参与者
参与者
(Actor)、用例(Use Case)、系统边界、箭头组成,用画图的方法来完成。

参与者

参与者不是特指人,是指系统以外的,在使用系统或与系统交互中所扮演的角色。因此参与者可以是人,可以是事物,也可以是时间或其他系统等等。还有一点要注意的是,参与者不是指人或事物本身,而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员,他参与图书馆管理系统的交互,这时他既可以作为管理员这个角色参与管理,也可以作为借书者向图书馆借书,在这里小明扮演了两个角色,是两个不同的参与者。参与者在画图中用简笔人物画来表示,人物下面附上参与者的名称。

用例

用例

用例

用例

是对包括变量在内的一组动作序列的描述,系统执行这些动作,并产生传递特定参与者的价值的可观察结果。这是UML对用例的正式定义,对我们初学者可能有点难懂。我们可以这样去理解,用例是参与者想要系统做的事情。对于对用例的命名,我们可以给用例取一个简单、描述性的名称,一般为带有动作性的词。用例在画图中用椭圆来表示,椭圆下面附上用例的名称。


系统边界

系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分,边界外表示系统外部。系统边界在画图中用方框来表示,同时附上系统的名称,参与者画在边界的外面,用例画在边界里面。因为系统边界的作用有时候不是很明显,所以我个人理解,在画图时可省略。

箭头

箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方,箭头头部用来表示被启动的一方,其中用例总是要由参与者来启动。


2  类图

类图(Class diagram)是显示了模型的静态结构,特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。类图不显示暂时性的信息。类图是面向对象建模的主要组成部分。它既用于应用程序的系统分类的一般概念建模,也用于详细建模,将模型转换成编程代码。类图也可用于数据建模。

from clipboard

3 对象图

对象图(Object Diagram) 是显示了一组对象和他们之间的关系。使用对象图来说明数据结构,类图中的类或组件等的实例的静态快照。

from clipboard

4  包图

包图是在 UML 中用类似于文件夹的符号表示的模型元素的组合。系统中的每个元素都只能为一个包所有,一个包可嵌套在另一个包中。使用包图可以将相关元素归入一个系统。一个包中可包含附属包、图表或单个元素。

from clipboard

5 顺序图


一:定义

1,UML顺序图一般用于确认和丰富一个使用情境的逻辑。
2,一个使用情境的逻辑或是一个用例的一部分;或是一条扩展路径;或是一个贯穿单个用例的完整路径,例如动作基本过程的逻辑描述;或是动作的基本过程的一部分再加上一个或多个的备用情境的逻辑描述;或是包含在几个用例中的路径。

3,顺序图将交互关系表现为一个二维图,纵向是时间轴,时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色,类元角色的活动用生命线表示。

二:顺序图示例

三:顺序图的组成元素

1,生命线用一条纵向虚线表示。

2,在UML中,对象表示为一个矩形,其中对象名称标有下划线。

3,激活是过程的执行,包括等待过程执行的时间。在顺序图中激活部分替换生命线,使用长条的矩形表示。

4,消息是对象之间的通信,是两个对象之间的单路通信,是从发送者到接收者之间的控制信息流。消息在顺序图中由有标记的箭头表示,箭头从一个对象的生命线指向另一个对象的生命线,消息按时间顺序在图中从上到下排列。

5,在顺序图中,对象安排在X轴。启动交互的对象放在最左边,随后放入消息的对象放在启动交互对象的右边。交互中对象发送和接收的消息沿着Y轴以时间增加的次序放置。在顺序图中,有的消息对应于激活,表示它将会激活一个对象,这种消息称为调用消息(Call Message);如果消息没有对应激活框,表示它不是一个调用消息,不会引发其他对象的活动,这种消息称为发送消息(Send Message)。

6,消息

>调用消息

>返回消息

>自身消息



>调用消息

>发送消息


>创建消息

>销毁消息


>同步消息:发送消息的对象要等到接收消息的对象执行完所有操作后,发送消息的对象才能继续执行自己的操作。

>异步消息:发送消息的对象发送消息后,不用等待接收对象是否执行,继续执行自己的操作。


7,交互片段

一个复杂的顺序图可以划分为几个小块,每一个小块称为一个交互片段。每个交互片段由一个大方框包围,其名称显示在方框左上角的间隔区内,表示该顺序图的信息。常用操作符如下:
>alt:多条路径,条件为真时执行。
>opt:任选,仅当条件为真时执行。
>par:并行,每一片段都并发执行。
>loop:循环,片段可多次执行。
>critical:临界区,只能有一个线程对它立即执行。

四:顺序图的作用

1,对于业务人员,顺序图可显示不同的业务对象如何交互,对于交流当前业务如何进行很有用。除记录组织的当前事件外,一个业务级的顺序图能被当作一个需求文件使用,为实现一个未来系统传递需求。

2,对于需求分析人员,顺序图能通过提供一个深层次的表达,把用例带入下一层次。通常用例被细化为一个或者更多的顺序图。顺序图的主要用途之一,是把用例表达的需求,转化为进一步、更深层次的精细表达。
3,对于技术人员,顺序图在记录一个未来系统的行为应该如何表现时非常有用。在设计阶段,架构师和开发者能使用顺序图挖掘出系统对象间的交互,进一步完善整个系统的设计。

五:顺序图绘制技巧

1,以用例为单位创建顺序图,针对每个用例,考察为完成它所描述的功能需要哪些对象的操作参与执行,并且进一步考察这些操作的执行需要通过消息而引起其他哪些对象操作的执行。把这些对象以及参与交互的执行者组织到一个顺序图中。

2,理论上需要为每一个用例创建一个顺序图,但是如果一个用例的交互对象很简单可以不需要创建顺序图。

3,顺序图绘制步骤:
>确定参与交互的执行者
>确定与执行者直接交互的对象
>确定与交互相关的全部对象(顺藤摸瓜)

4,

>如果需要考察单个用例内部多个对象的行为可以使用顺序图;
>如果需要考察单个对象的行为就需要使用状态图;
>如果需要考察跨用例或者跨线程的行为就需要考虑使用活动图。

5,

>需求分析阶段的顺序图:主要用于描述用例中对象之间的交互,可以使用自然语言来绘制,用于细化需求。从业务的角度进行建模,用描述性的文字叙述消息的内容。

>系统设计阶段的顺序图:确切表示系统设计中对象之间的交互,考虑到具体的系统实现,对象之间通过方法调用传递消息。

六:实例

>绘制图书管理系统“借书”用例的顺序图(业务模型)。
图书管理员打开借书界面,输入借书信息并提交借书请求;系统验证借书卡状态,如果借书卡未借书则记录借书信息且修改图书状态和借书卡状态,并提示借书成功;否则提示借书失败。

>绘制图书管理系统“还书”用例的顺序图(业务模型)。
图书管理员打开还书界面,输入还书信息并提交还书请求;系统返回借书详细信息及所需金额;图书管理员输入金额;系统修改借书记录并修改图书状态和借书卡状态;提示还书成功。

6 通信图


通信图的概念:通信图(协作图)是表现对象交互关系的图,它展现了多个对象在协同工作达成共同目标的过程中互相通信的情况,通过对象和对象之间的链、发送的消息来显示参与交互的对象。

首先通信图一样是一种交互图,它描述的是对象和对象之间的关系,即一个类操作的实现。简而言之就是,对象和对象之间的调用关系,体现的是一种组织关系。

通信图中的元素主要有对象、消息和链三种。对象和链分别作为通信图中的类元角色和关联角色出现,链上可以有消息在对象间传递

从结构方面来看,通信图包含了一个对象的集合并且定义了它们之间的行为方面的关系,表达了一些系统的静态内容。

从行为方面来看,通信图包含了在各个对象之间进行传递交换的一系列的消息集合,以完成协作的目的。

通信图是一种描述协作在某一语境下的空间组织结构的图形化方式,在使用其进行建模时,主要具有以下三个作用。

1)通过描绘对象之间消息的传递情况来反映具体使用语境的逻辑表达。

2)显示对象及其交互关系的空间组织结构。

3)表达一个操作的实现。

 

通信图的组成元素: 对象、链、消息

 

对象

通信图中的对象与顺序图中对象的概念相同,都是表示类的实例。

通信图只关注相互有交互作用的对象和对象关系,而忽略其他对象。

由于通信图中不表示对象的创建与销毁,因此,对象在通信图中的位置没有限制。

与顺序图中对象的表示法不同的是,通信图中的无法显示对象的生命线。

 

通信图中的链与对象图中的链在语义以及表示法上都相同,都是两个(或多个)对象之间的独立连接,是关联的实例。链同时也是通信图中关联角色的实例,其生命受限于协作的生命。

链连接的两个对象之间允许在交互执行过程中进行消息传递和交互。UML也允许对象自身与自身之间建立一条链。链可以通过对自己命名来进行区分和说明,也可以仅仅做连接而不进行命名。

 

 

消息

通信图的消息需要附加在对象之间的链上,链用于传输或实现消息的传递。

通信图中的消息通过在链的上方或下方添加一个短箭头来表示,通常需要使用阿拉伯数字作为序号来表示通信图中发送消息的顺序。

 

 

 

通信图与顺序图的异同点:

通信图与顺序图的共同点主要有如下3点:

1)主要元素相同。两种图中的主要元素都是对象与消息,且都支持所有的消息类型。

2)表达语义相同。两种图都是对系统中的交互建模,描述了系统中某个用例或操作的执行过程,二者的语义是等价的。

3)对象责任相同。两种图中的对象都担任了发送者与接收者的角色并承担了发送与接收消息的责任。通过对象之间消息的传递来实现系统的功能。

 

两种图之间的不同点也有如下3点:

1)通信图偏重于将对象的交互映射到连接它们的链上,这有助于验证类图中对应的类之间关联关系的正确性或建立新的关联关系的必要性。然而顺序图偏重描述交互中消息传递的逻辑顺序。因此通信图更适用于展示系统中的对象结构,而顺序图则擅长表现交互中消息的顺序。

2)顺序图可以显式地表现出对象创建与撤销的过程,而在通信图中,只能通过消息的描述隐式地表现这一点。

3)顺序图还可以表示对象的激活情况,而对于通信图来说,由于缺少表示时间的信息,除了对消息进行解释,无法清晰地表示对象的激活情况。

 

 

通信图与顺序图对比

 

时序图

通信图

 

通信图建模技术

按组织对控制流建模

识别交互的语境,即交互所处的环境。

识别出图中应该存在的对象。

识别可能有消息传递的对象并设置链。

设置对象间的消息。

如果需要更多约束,如时间或空间的约束,可以使用其他的约束来修饰这些消息。

 

 

案例(1)添加新书

 

 

案例(2)学位初评

教务人员通过学号在学位初评系统查询学生的初评情况。学位初评系统分别在成绩管理系统、奖罚管理系统、毕业设计管理系统查询成绩、奖罚、毕业设计情况。并根据情况生成学位初评结果,通过信息打印模块打印初评情况。

 

 

 

案例(3)登录系统

 

案例(4)添加用户信息

7  状态图

状态图(Statechart Diagram)是描述一个实体基于事件反应的动态行为,显示了该实体如何根据当前所处的状态对不同的事件做出反应。通常我们创建一个UML状态图是为了以下的研究目的:研究类、角色、子系统、或组件的复杂行为。

 from clipboard

from clipboard




 
关键词:视图模型  

 评论 01 / 1

相关资源