itgle.com

Kruchten提出的“4+1”视图模型,提倡从不同维度看软件架构。()可以看作是那些重要系统活动的抽象,它使四个视图有机联系起来,从某种意义上说场景是最重要的需求抽象。()A.逻辑视图 B.进程视图 C.物理视图 D.场景

题目

Kruchten提出的“4+1”视图模型,提倡从不同维度看软件架构。()可以看作是那些重要系统活动的抽象,它使四个视图有机联系起来,从某种意义上说场景是最重要的需求抽象。()A.逻辑视图 B.进程视图 C.物理视图 D.场景


相似考题
参考答案和解析
正确答案:D
    Kruchten提出的“4+1”视图模型,提倡从不同维度看软件架构。这些维度包括:逻辑视图、进程视图、开发视图、物理视图、场景。
    (1)逻辑视图。逻辑视图主要支持系统的功能需求,即系统提供给最终用户的服务。在逻辑视图中,系统分解成一系列的功能抽象,这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析,而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。在OO技术中,通过抽象、封装和继承,可以用对象模型来代表逻辑视图,用类图来描述逻辑视图。逻辑视图中使用的风格为面向对象的风格,在设计中要注意保持一个单一的、内聚的对象模型贯穿整个系统。
    (2)开发视图。开发视图也称为模块视图,在UML中被称为实现视图,它主要侧重于软件模块的组织和管理。开发视图要考虑软件内部的需求,例如,软件开发的容易性、软件复用和软件的通用性,要充分考虑由于具体开发工具的不同而带来的局限性。开发视图通过系统I/O关系的模型图和子系统图来描述。
    (3)进程视图。进程视图侧重于系统的运行特性,主要关注一些非功能性需求,例如,系统的性能和可用性等。进程视图强调并发性、分布性、系统集成性和容错能力,以及逻辑视图中的功能抽象如何适合进程结构等,它也定义了逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。进程视图可以描述成多层抽象,每个级别分别关注不同的方面。
    (4)物理视图。物理视图在UML中被称为部署视图,它主要考虑如何把软件映射到硬件上,它通常要考虑到解决系统拓扑结构、系统安装和通信等问题。当软件运行于不同的物理节点上时,各视图中的构件都直接或间接地对应于系统的不同节点上。因此,从软件到节点的映射要有较高的灵活性,当环境改变时,对系统其他视图的影响最小化。
    (5)场景。场景可以看作是那些重要系统活动的抽象,它使四个视图有机联系起来,从某种意义上说场景是最重要的需求抽象。场景视图对应UML中的用例视图。在开发软件架构时,它可以帮助架构设计师找到构件及其相互关系。同时,架构设计师也可以用场景来分析一个特定的视图,或描述不同视图的构件之间是如何相互作用的。
更多“Kruchten提出的“4+1”视图模型,提倡从不同维度看软件架构。()可以看作是那些重要系统活动的抽象,它 ”相关问题
  • 第1题:

    软件架构为软件系统提供了一个结构、行为和属性的高级抽象模式。“4+1”视图模型指用5个视图组成的模型来描述软件架构。其中,(50)描述了软件的静态组织结构,支持软件开发的内部需求。

    A.物理视图

    B.逻辑视图

    C.进程视图

    D.开发视图


    正确答案:D
    解析:软件架构是指大型、复杂软件系统结构的设计、规格说明和实施。它以规范的形式装配若干结构元素,从而描述出系统的主要功能和性能要求,同时表述其他非功能性需求(如可靠性、可扩展性、可移植性和可用性等)。软件架构为软件系统提供了一个结构、行为和属性的高级抽象模式,可以使用公式“软件架构={构成系统的元素,指导元素集成的形式,关系和约束}”来表达。
      “4+1”视图模型用5个视图组成的模型来描述软件架构。该模型包含5个主要视图及其实现的功能如表7-7所示。

  • 第2题:

    Philippe kruchten提出的4+1视图模型从( )几个方面来描述软件需求。
    ①逻辑视图 ②进程视图 ③物理视图 ④开发视图 ⑤数据流视图 ⑥场景视图

    A. ③④⑤⑥
    B. ①②③④
    C. ①②③④⑥
    D. ①③④⑤⑥

    答案:C
    解析:
    4+1视图模型从五个不同的视角来描述软件体系结构,每个视角只关心系统的一个侧面,五个视角结合在一起才能反映软件体系结构的全部内容。这五个视角分别为:
    1. 逻辑视图:主要支持系统的功能需求,它直接面向最终用户;
    2. 开发视图:主要支持软件模块的组织和管理,它直接面向编程人员;
    3. 进程视图:主要关注一些非功能性的需求,如系统的性能和可用性等,它直接面向系统集成人员;
    4. 物理视图:主要关注如何把软件映射到硬件上,通常要解决系统的拓扑结构、系统安装、通信等问题,它直接而向系统工程人员;
    5. 场景视图:是重要系统活动的抽象描述,可以使上述四个视图有机联系起来,可认为是最重要的需求抽象。
    其中,逻辑视图、开发视图描述系统的静态结构,进程视图和物理视图描述系统的动态结构。

  • 第3题:

    架构设计使用4+1视图模型描述系统设计,从5个不同的视角来描述软件体系结构。


    1)用例图定义了系统的功能需求它完全是从系统的外部观看系统功能并不描述系统内部对功能的具体实现。在用例图中角色代表触发系统功能的用户或其他系统用例代表具体的功能描述。2)类图描述系统的静态结构表示系统中的类以及类与类之间的关系。3)对象图描述了一组对象以及它们之间的关系表示类的对象实例。4)状态图表示一个状态机强调对象行为的事件顺序。5)时序图和协作图均表示一组对象之间的动态协作关系。其中时序图反映对象之间发送消息的时间顺序协作图反映收发消息的对象的结构组织。时序图和协作图是同构 1)用例图定义了系统的功能需求,它完全是从系统的外部观看系统功能,并不描述系统内部对功能的具体实现。在用例图中,角色代表触发系统功能的用户或其他系统,用例代表具体的功能描述。2)类图描述系统的静态结构,表示系统中的类以及类与类之间的关系。3)对象图描述了一组对象以及它们之间的关系,表示类的对象实例。4)状态图表示一个状态机,强调对象行为的事件顺序。5)时序图和协作图均表示一组对象之间的动态协作关系。其中,时序图反映对象之间发送消息的时间顺序,协作图反映收发消息的对象的结构组织。时序图和协作图是同构 解析:用例描述了它所代表的功能的各个方面,即包含了用例执行期间可能发生的各种情况。用例和角色之间具有“关联”的连接关系,表示什么角色与该用例进行通信。在UML语言中,用例用一个椭圆图形和名称表示。 在本题中,我们通过题目说明可以识别以下用例: 1.与教师有关的用例 1)选择课程——选择所教的课程,并获得学生名册。 2)登记成绩——在学期结束时,提交学生的课程成绩。 2.与学生有关的用例 1)注册课程——在学期开始进行选课注册,允许在一段时间内更改或删除,课程目录系统提供当前学期的所有可选课程列表。2)查看成绩单——学生可以查看以前学期的电子成绩单。 3.与注册管理员有关的用例 1)维护课程信息——在系统中增加、修改和删除课程信息。2)维护学生信息——在系统中增加、修改和删除学生信息。3)维护教师信息——在系统中增加、修改和删除教师信息。4)关闭注册——删除少于3人的课程,并由付费系统通知学生缴费。 4.与安全性要求有关的用例 登录——使用此系统的人员需要进行登录,以验证其身份和权限。 发现和定义对象类应以问题域和系统责任为出发点,正确地运用抽象原则,尽可能全面地发现对象的因素,并对其进行检查和整理,最终得到系统的对象类。我们可以在用例模型的基础上,通过识别实体类、边界类和控制类,从而发现和定义系统中的对象类。识别上述对象类之后,通过建立交互图,将用例的行为分布到这些对象类中。时序图表示完成某项行为的对象类和这些对象类之间传递消息的时间顺序,其中,对象生命线是一条垂直的虚线,表示对象存在的时间;控制焦点是一个细长的矩形,表示对象执行一个所经历的时间段;消息是对象之间的一条水平箭头线,表示对象之间的通信。协作图包含一组对象和以消息交换为纽带的关联,用于描述系统的行为是如何由系统的成分合作实现的。

  • 第4题:

    ● Philippe Kruchten提出的4+1视图模型从__(8)__几个方面来描述软件需求。

    ①逻辑视图 ②进程视图 ③物理视图 ④开发视图 ⑤数据流视图 ⑥场景视图

    (8)A.③④⑤⑥ B.①②③④

    C.①②③④⑥ D.①③④⑤⑥


    正确答案:C
    逻辑视图(LogicalView),设计的对象模型(使用面向对象的设计方法时)。处理视图(ProcessView),捕捉设计的并发和同步特征,又叫过程视图、进程视图。开发视图(DevelopmentView),描述了在开发环境中软件的静态组织结构。显示了源代码与实际执行代码的组织结构,又叫组件视图,实现视图。物理视图(PhysicalView),描述了软件到硬件的映射,反映了分布式特性。又叫部署视图架构的描述,即所做的各种决定,可以围绕着这四个视图来组织,然后由一些用例(usecases)或场景(scenarios)来说明,从而形成了第五个视图—场景视图。

  • 第5题:

    架构设计使用4+1视图模型描述系统设计,从5个不同的视角来描述软件体系结构。 ()


    1)用例图定义了系统的功能需求它完全是从系统的外部观看系统功能并不描述系统内部对功能的具体实现。在用例图中角色代表触发系统功能的用户或其他系统用例代表具体的功能描述。2)类图描述系统的静态结构表示系统中的类以及类与类之间的关系。3)对象图描述了一组对象以及它们之间的关系表示类的对象实例。4)状态图表示一个状态机强调对象行为的事件顺序。5)时序图和协作图均表示一组对象之间的动态协作关系。其中时序图反映对象之间发送消息的时间顺序协作图反映收发消息的对象的结构组织。时序图和协作图是同构 1)用例图定义了系统的功能需求,它完全是从系统的外部观看系统功能,并不描述系统内部对功能的具体实现。在用例图中,角色代表触发系统功能的用户或其他系统,用例代表具体的功能描述。2)类图描述系统的静态结构,表示系统中的类以及类与类之间的关系。3)对象图描述了一组对象以及它们之间的关系,表示类的对象实例。4)状态图表示一个状态机,强调对象行为的事件顺序。5)时序图和协作图均表示一组对象之间的动态协作关系。其中,时序图反映对象之间发送消息的时间顺序,协作图反映收发消息的对象的结构组织。时序图和协作图是同构 解析:用例描述了它所代表的功能的各个方面,即包含了用例执行期间可能发生的各种情况。用例和角色之间具有“关联”的连接关系,表示什么角色与该用例进行通信。在UML语言中,用例用一个椭圆图形和名称表示。 在本题中,我们通过题目说明可以识别以下用例: 1.与教师有关的用例 1)选择课程——选择所教的课程,并获得学生名册。 2)登记成绩——在学期结束时,提交学生的课程成绩。 2.与学生有关的用例 1)注册课程——在学期开始进行选课注册,允许在一段时间内更改或删除,课程目录系统提供当前学期的所有可选课程列表。2)查看成绩单——学生可以查看以前学期的电子成绩单。 3.与注册管理员有关的用例 1)维护课程信息——在系统中增加、修改和删除课程信息。2)维护学生信息——在系统中增加、修改和删除学生信息。3)维护教师信息——在系统中增加、修改和删除教师信息。4)关闭注册——删除少于3人的课程,并由付费系统通知学生缴费。 4.与安全性要求有关的用例 登录——使用此系统的人员需要进行登录,以验证其身份和权限。 发现和定义对象类应以问题域和系统责任为出发点,正确地运用抽象原则,尽可能全面地发现对象的因素,并对其进行检查和整理,最终得到系统的对象类。我们可以在用例模型的基础上,通过识别实体类、边界类和控制类,从而发现和定义系统中的对象类。识别上述对象类之后,通过建立交互图,将用例的行为分布到这些对象类中。时序图表示完成某项行为的对象类和这些对象类之间传递消息的时间顺序,其中,对象生命线是一条垂直的虚线,表示对象存在的时间;控制焦点是一个细长的矩形,表示对象执行一个所经历的时间段;消息是对象之间的一条水平箭头线,表示对象之间的通信。协作图包含一组对象和以消息交换为纽带的关联,用于描述系统的行为是如何由系统的成分合作实现的。