架构“4+1”视图及几种 UML 图的解释

架构“4+1”视图及几种 UML 图的解释一、“4+1”视图模型从五个不同的视角来描述软件架构,每个视图只关心系统的一个侧面,五个视图结合在一起才能反映软件架构的全部内容。(1)逻辑视图

大家好,欢迎来到IT知识分享网。

一、“4+1”视图模型从五个不同的视角来描述软件架构,每个视图只关心系统的一个侧面,五个视图结合在一起才能反映软件架构的全部内容。

(1)逻辑视图。逻辑视图主要支持系统的功能需求,即系统提供给最终用户的服务。在逻辑视图中,系统分解成一系列的功能抽象,这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析,而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。在 OO 技术中,通过抽象、封装和继承,可以用对象模型代表逻辑视图,用类图描述逻辑视图。逻辑视图中使用的风格为面向对象的风格,在设计中要注意保持一个单一的内聚的对象模型贯穿整个系统。

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

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

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

(5)场景。场景可以看作是那些重要系统活动的抽象,它使四个视图有机联系起来,从某种意义上说场景是最重要的需求抽象。场景视图对应 UML 中的用例视图。在开发软件架构时,它可以帮助架构设计师找到构件及其相互关系。同时,架构设计师也可以用场景来分析一个特定的视图,或描述不同视图的构件之间是如何相互作用的。场景可以用文本表示,也可以用图形表示。

二、下面是几种 UML 图的解释:

(1)对象图(object diagram)。对象图描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。和类图一样,这些图给出系统的静态设计视图或静态进程视图,但它们是从真实案例或原型案例的角度建立的。

(2)活动图(activity diagram)。活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模和业务流程建模特别重要,并强调对象间的控制流程。

(3)状态图(state diagram)。状态图描述一个状态机,它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要,而且它强调事件导致的对象行为,这非常有助于对反应式系统建模。

(4)类图(class diagram)。类图描述一组类、接口、协作和它们之间的关系。在 OO 系统的建模中,最常见的图就是类图。类图给出了系统的静态设计视图,活动类的类图给出了系统的静态进程视图。

三、主要用于描述系统逻辑架构,最早由 Philippe Kruchten 于 1995 年提出。其中逻辑视图用于描述对象模型,并说明系统应该为用户提供哪些服务。当采用面向对象的设计方法描述对象模型时,通常使用类图表达类的内部属性和行为,以及类集合之间的交互关系;采用活动图“4+1”视图定义对象的内部行为

免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://yundeesoft.com/54880.html

(0)

相关推荐

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

关注微信