利用“4+1”视图建模方法进行“网上选课系统”软件体系结构设计
- 格式:doc
- 大小:1.79 MB
- 文档页数:20
基于UML4+1视图和概念模型的建模⽅法RUP的4+1视图包括: 逻辑视图:关注功能性的、整个系统的抽象结构,不涉及具体的编译即输出和部署。
开发视图:是逻辑视图的实现,描述程序⽣成多少个exe、dll、jar、配置⽂件等。
⼜叫实现视图。
运⾏视图:关注程序运⾏时各个⼦系统、组件之间的交互策略。
如多进程、多线程,⽣产者-消费者模式。
运⾏视图⼜称过程视图。
部署视图:关注软件交付以后在机器上的部署形态,以及和上下⽂的关系。
⼜称物理视图。
⽤例视图:关注需求,⼜叫场景视图。
RUP 4+1视图相对完整的描述了从需求分析到系统设计的过程,但没有专门针对数据持久层的描述。
温li在软件架构设计中⽤数据视图替换了⽤例视图,应该说他相对重视架构设计,对需求关注的少⼀些。
关于需求的描述⽅法,应当清醒的看到,仅仅通过⽤例视图是不够的,⽤例技术涉及、但⽆法全⾯涵盖⾮功能需求。
需求 = 功能 + 质量+ 约束。
⼤量的信息还是要通过详细的⽂字描述才能够讲清楚。
⽤例视图只不过提供了描述了⼀个软件的需求概貌。
除了⽤例视图以外,还应该关注软件的概念模型(⼜称领域模型、信息模型)。
如果说⽤例着重于描述⼀个个具体的需求,概念模型则从业务的⾓度描述了整个软件系统所要完成的功能中涉及的所有概念以及彼此之间的关系。
例如对于⼀个⽹管系统,核⼼的两个概念是设备和端⼝,端⼝从属于设备,他们之间是多对⼀的关系。
分别详述4+1视图:逻辑视图关注的静态元素是:层、⼦系统、类、接⼝,⽤类图来描述。
关注的动态因素是协作关系,⽤时序图、协作图、状态图等来描述。
是否需要在架构设计中体现类和类之间的关系?这取决于设计的层级。
开发视图关注的元素是程序包(SDK、解析器、中间件)、⽂件组织结构、编译依赖关系、⽬标单元(jar、exe、dll等)。
它和逻辑视图的静态元素通常有映射关系。
运⾏视图关注进程、线程、对象等运⾏时概念,以及相关的并发、同步、通信等问题。
运⾏架构和开发架构的关系:开发架构⼀般偏重程序包在编译时期的静态依赖关系,⽽这些程序运⾏起来之后会表现为对象、线程、进程,运⾏架构⽐较关注的是这些运⾏时单元的交互问题。
“4+1”模型学生信息管理系统分析与设计“4+1”模型概述Kruchten在1995年提出了“4+1”的视图模型。
“4+1”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。
每一个视图只关心系统的一个侧面,5个视图结合在一起才能反映系统的软件体系结构的全部内容。
1,逻辑视图逻辑视图(logic view)主要支持系统的功能需求,即系统提供给最终用户的服务。
在逻辑视图中,系统分解成一系列的功能抽象,这些抽象主要来自问题领域。
这种分解不但可以用来进行功能分析,而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。
在面向对象技术中,通过抽象、封装和继承,可以用对象模型来代表逻辑视图,用类图(class diagram)来描述逻辑视图。
可以从Booch标记法中导出逻辑视图的标记法,只是从体系结构级的范畴来考虑这些符号,用Rational Rose 进行体系结构设计。
类图用于表示类的存在以及类与类之间的相互关系,是从系统构成的角度来描述正在开发的系统。
一个类的存在不是孤立的,类与类之间以不同的方式互相合作,共同完成某些系统功能。
关联关系表示两个类之间存在着某种语义上的联系,其真正含义要有附加在横线之上的一个短语来予以说明。
在表示包含关系的图符中,带有实心圆的一端表示整体,相反的一端表示部分。
在表示使用关系的图符中,带有空心圆的一端连请求服务的类,相反的一端连接提供服务的类。
在表示继承关系的图符中,箭头由子类指向基类。
逻辑视图中使用的风格为面向对象的风格,逻辑视图设计中要注意的主要问是要保持一个单一的、内聚的对象模型贯穿整个系统。
对于规模更大的系统来说,体系结构级中包含数十甚至数百个类。
2,开发视图开发视图(development view)也称模块视图(module view),主要侧重于软件模块的组织和管理。
软件可以通过程序库或子系统进行组织,这样,对于一个软件系统,就可以由不同的人进行开发。
基于“4+1”模型的学生信息管理系统的分析与设计Based on the "4 + 1" model students' information management system analysis and design摘要:随着计算机的发展以及网络技术的应用,当今社会正快速向信息化社会迈进,信息自动化融人日常生活中,使人们从烦琐的事务中解放出来.随着高校招生规模的不断扩大,面对庞大的信息t,需要一个学生信息管理系统来提高对学生信息管理的工作效率。
本文以UML描述为基础,建立学生信息管理“4+1”视图模型,从系统的多个视图描述软件体系结构出发以后提高软件开发效率、平均软件质量与开发周期的矛盾。
Absract:With the development of the computer and network technology application,today's society is rapidly to the information society forward,the information automation into daily life,make people in the affairs of loaded down with trivial details from liberating. With the constant expansion of college enrollment,facing huge informationt, need a students' information management system to improve the students' information management work efficiency.This paper described in UML,based students' information management "4 + 1" view model,from the system of more views describe software system structure of improving the efficiency of software development,after an average software quality and development cycle of conflict.关键字:“4+1”视图模型学生信息管理系统建模语言The Unified Modeling Language(UML)Keywords:The "4 + 1" view model Students' information management system Modeling Language The Unified Modeling Language (UML)随着学校的规模不断扩大,学生数量急剧增加,有关学生的各种信息量也成倍增长。
本文基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。
使用多重视图允许独立地处理各"风险承担人":最终用户、开发人员、系统工程师、项目经理等所关注的问题,并且能够独立地处理功能性和非功能性需求。
本文分别对五种视图进行了描述,并同时给出了捕获每种视图的表示方法。
这些视图使用以架构为中心的、场景驱动以及迭代开发过程来进行设计。
引言我们已经看到在许多文章和书籍中,作者欲使用单张视图来捕捉所有的系统架构要点。
通过仔细地观察这些图例中的方框和箭头,不难发现作者努力地在单一视图中表达超过其表达限度的蓝图。
方框是代表运行的程序吗?或者是代表源代码的程序块吗?或是物理计算机吗?或仅仅是逻辑功能的分组吗?箭头是表示编译时的依赖关系吗?或者是控制流吗?或是数据流吗?通常它代表了许多事物。
是否架构只需要单个的架构样式?有时软件架构的缺陷源于过早地划分软件或过分的强调软件开发的单个方面:数据工程、运行效率、开发策略和团队组织等。
有时架构并不能解决所有"客户"(或者说"风险承担人",USC 的命名)所关注的问题。
许多作者都提及了这个问题:Garlan & Shaw 1、CMU 的Abowd & Allen、SEI 的Clements。
作为补充,我们建议使用多个并发的视图来组织软件架构的描述,每个视图仅用来描述一个特定的所关注的方面的集合。
架构模型软件架构用来处理软件高层次结构的设计和实施。
它以精心选择的形式将若干结构元素进行装配,从而满足系统主要功能和性能需求,并满足其他非功能性需求,如可靠性、可伸缩性、可移植性和可用性。
Perry 和Wolfe 使用一个精确的公式来表达,该公式由Boehm 做了进一步修改:软件架构={元素,形式,关系/约束}软件架构涉及到抽象、分解和组合、风格和美学。
我们用由多个视图或视角组成的模型来描述它。
为了最终处理大型的、富有挑战性的架构,该模型包含五个主要的视图(请对照图1):∙逻辑视图(Logical View),设计的对象模型(使用面向对象的设计方法时)。
本文基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。
使用多重视图允许独立地处理各"风险承担人":最终用户、开发人员、系统工程师、项目经理等所关注的问题,并且能够独立地处理功能性和非功能性需求。
本文分别对五种视图进行了描述,并同时给出了捕获每种视图的表示方法。
这些视图使用以架构为中心的、场景驱动以及迭代开发过程来进行设计。
引言我们已经看到在许多文章和书籍中,作者欲使用单张视图来捕捉所有的系统架构要点。
通过仔细地观察这些图例中的方框和箭头,不难发现作者努力地在单一视图中表达超过其表达限度的蓝图。
方框是代表运行的程序吗?或者是代表源代码的程序块吗?或是物理计算机吗?或仅仅是逻辑功能的分组吗?箭头是表示编译时的依赖关系吗?或者是控制流吗?或是数据流吗?通常它代表了许多事物。
是否架构只需要单个的架构样式?有时软件架构的缺陷源于过早地划分软件或过分的强调软件开发的单个方面:数据工程、运行效率、开发策略和团队组织等。
有时架构并不能解决所有"客户"(或者说"风险承担人",USC 的命名)所关注的问题。
许多作者都提及了这个问题:Garlan & Shaw 1、CMU 的 Abowd& Allen、SEI 的Clemen ts。
作为补充,我们建议使用多个并发的视图来组织软件架构的描述,每个视图仅用来描述一个特定的所关注的方面的集合。
架构模型软件架构用来处理软件高层次结构的设计和实施。
它以精心选择的形式将若干结构元素进行装配,从而满足系统主要功能和性能需求,并满足其他非功能性需求,如可靠性、可伸缩性、可移植性和可用性。
Perry和 Wolfe使用一个精确的公式来表达,该公式由 Boehm做了进一步修改:软件架构={元素,形式,关系/约束}软件架构涉及到抽象、分解和组合、风格和美学。
案例教学1:4+1视图方法进行软件体系结构设计要开发出用户满意的软件并不是件容易的事,软件体系结构师必须全面把握各种各样的需求、权衡需求之间有可能的矛盾之处,分门别类地将不同需求一一满足。
本文从理解需求种类的复杂性谈起,通过具体案例的分析,展示了如何通过RUP的4+1视图方法,针对不同需求进行体系结构设计,从而确保重要的需求一一被满足。
1、呼唤体系结构设计的多重视图方法灵感一闪,就想出了把大象放进冰箱的办法,这自然好。
但希望每个体系结构设计策略都依靠灵感是不现实的--我们需要系统方法的指导。
需要体系结构设计的多重视图方法,从根本上来说是因为需求种类的复杂性所致。
以工程领域的例子开道吧。
比如设计一座跨江大桥:我们会考虑"连接南北的公路交通"这个"功能需求",从而初步设计出理想化的桥墩支撑的公路桥方案;然后还要考虑造桥要面临的"约束条件",这个约束条件可能是"不能影响万吨轮从桥下通过",于是细化设计方案,规定桥墩的高度和桥墩之间的间距;另外还要顾及"大桥的使用期质量属性",比如为了"能在湍急的江流中保持稳固",可以把大桥桥墩深深地建在岩石层之上,和大地浑然一体;其实,"建造期间的质量属性"也很值得考虑,比如在大桥的设计过程中考虑"施工方便性"的一些措施。
和工程领域的功能需求、约束条件、使用期质量属性、建造期间的质量属性等类似,软件系统的需求种类也相当复杂,具体分类如图1所示。
图1 软件需求分类的复杂性2、超市系统案例:理解需求种类的复杂性例子是最好的老师。
为了更好地理解软件需求种类的复杂性,我们来分析一个实际的例子。
在表1中,我们列举了一个典型的超市系统的需求子集,从这个例子中可以清晰地看到需求可以分为两大类:功能需求和非功能需求。
表1 超市系统案例:理解需求种类的复杂性简单而言,功能需求就是"软件有什么用,软件需要做什么"。
选课系统体系结构设计一、引言选课系统是现代高等教育中必不可少的重要组成部分,它为学生提供了方便、快捷的课程选择途径,同时也为学校和教职工提供了管理和分配资源的手段。
本文将针对选课系统的体系结构进行设计,旨在提供一个高效、稳定和可扩展的系统架构。
二、系统需求分析1. 用户需求选课系统的用户主要包括学生、教职工和管理员。
学生希望能够方便地查看和选择自己的课程,教职工需要能够发布和管理课程信息,管理员则需要具备对整个系统进行维护和管理的权限。
2. 功能需求选课系统应该具备以下功能:- 学生能够浏览、搜索和筛选课程信息;- 学生能够选择和退选课程;- 教职工能够发布和管理课程信息;- 系统能够自动进行选课结果的计算和统计;- 系统能够处理选课冲突和资源分配问题;- 管理员能够管理用户、课程和系统设置;- 系统能够提供数据备份和恢复功能。
3. 性能需求选课系统需要具备以下性能要求:- 快速响应:系统对于用户的请求需要有较快的响应速度,尽量减少等待时间;- 稳定可靠:系统应当具备高可用性和容错机制,确保系统能够持续稳定地运行;- 可扩展性:系统应能够根据需求的增加灵活地进行扩展,保证系统的性能和效率。
三、系统架构设计基于对选课系统需求的分析,我们提出了以下的系统架构设计方案:1. 前端设计前端是用户与系统进行交互的界面,对于选课系统而言,前端应具备良好的用户体验和友好的界面设计。
我们可以采用现代前端框架进行开发,如React、Angular等,以实现前后端分离和页面的动态渲染。
2. 后端设计后端负责处理前端的请求,并与数据库进行交互。
我们可以采用分布式架构,将后端拆分为多个服务,提高系统的性能和并发处理能力。
常用的后端开发框架有Spring Boot、Django等,可以根据具体需求进行选择。
3. 数据库设计选课系统的数据库设计对于系统的稳定性和数据一致性至关重要。
我们可以使用关系型数据库如MySQL或非关系型数据库如MongoDB,以满足系统的需要。
利用“4+1”视图建模方法进行“上选课系统”软件体系结构设计使用“4+1”视图建模方法设计“在线选课系统”的软件架构专业:软件工程等级类别:12月19日,XXXX1简介(1)使用4+1视图方法:针对不同需求的架构设计开发用户满意的软件并不容易,软件架构师必须Philippe Kruchten 提出的4+1视图方法为软件架构师逐个征服需求提供了良好的基础,如图1所示。
图1采用4+1视图方法设计不同需求的体系结构场景视图:场景视图侧重于案例描述,即案例软件需求的功能描述和非功能描述;对应于UML建模中的用例建模逻辑视图:逻辑视图关注功能,不仅包括用户可见的功能,还包括实现用户功能必须提供的辅助功能模块。
它们可以是逻辑层、功能模块等开发视图:开发视图关注包,它不仅包括要编写的源程序,还包括第三方SDK、现成的框架、类库和系统软件或中间件,开发的系统将在这些软件或中间件上运行。
开发视图和逻辑视图之间可能存在某种映射关系:例如,逻辑层通常映射到多个包,等等。
处理视图:处理视图关注运行时概念,如进程、线程、对象以及相关的并发、同步、通信和其他问题处理视图和开发视图之间的关系:开发视图通常强调编译时包的静态依赖性,这些程序在运行后将表现为对象、线程和进程。
这些运行时单元的交互是处理视图的焦点。
物理视图:物理视图关注于\目标程序及其依赖的运行时和系统软件\如何最终安装或部署到物理机器,以及如何部署机器和网络以满足软件系统的要求,如可靠性和可扩展性物理视图和处理视图的关系:处理视图特别关注目标程序的动态执行,而物理视图关注目标程序的静态位置;物理视图是一种体系结构视图,它综合考虑了软件系统和整个信息技术系统之间的交互。
(2)软件需求分类要求架构设计采用多视图方法,这主要是由于需求类型的复杂性软件需求包括功能性需求和非功能性需求非功能性需求包括质量属性和约束质量属性包括运行时质量属性和开发时质量属性。
软件需求的分类如图2所示。
南京邮电大学《软件体系结构》实验报告实验题目“4+1”视图描述体系结构实验 2 用“4+1”视图描述体系结构一、实验目的:理解“4+1 视图”建模思想,熟悉体系结构生命周期模型,掌握基于软件体系结构建模方法。
二、实验要求:实验课前完成实验报告的实验目的、实验环境、实验内容、实验操作过程等内容;实验课中独立/团队操作完成实验报告的实验操作、实验结果及结论等内容;每人一台PC 机,所需软件Win2003/XP、UML工具(EclipseUML/ Rose/Visio/StartUML/)、Eclipse/MyEclipse、JDK6.0 等。
实验课后完成实验报告的心得体会内容,并及时提交实验报告。
三、实验内容及操作步骤:(一)实验内容根据“4+1”视图对KWIC(关键词索引系统)系统建模,完成KWIC 系统的逻辑视图、过程视图、物理视图、开发视图和场景视图。
(二)操作步骤基于“4+1”视图,对KWIC(关键词索引系统)系统进行视图建模:1.建立KWIC 的逻辑视图采用面向对象的设计方法时,逻辑视图即是对象模型。
逻辑视图( Logical view)是为了便于理解系统设计的结构与组织,在“分析设计”工作流程中使用了名为逻钭视图的构架视图。
可以用对象模型米代表逻辑视图,用类图来描述逻辑视图。
系统只有一个逻辑视图,该视图以图形方式说明关键的用例实现、子系统、包和类,它们包含了在构架方面具有币要意义的行为。
逻辑视图在每次迭代过程中都会加以改进。
KWIC的逻辑视图如下所示:2.建立KWIC 的过程视图描述系统的并发和同步方面的设计。
过程视图process view)侧重于系统的运动特性,主要关注一些非功能性的需求,例如系统的性能和可用性。
过程视图强调并发性、分布性、系统集成性和容错能力,以及从逻辑视图中的主要抽象如何适合进程结构。
它也定义了逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。
KWlC的过程视图如下所示:3.建立KWIC 的物理视图描述软件到硬件之间的映射关系,反映系统在分布方面的设计。
案例2:网上选课系统二、设计建模(一)系统总体设计1、系统的体系架构“网上选课系统”是一个基于Web的网络应用系统,在进行软件体系架构分析时,我们采用了典型的三层架构模式(B/A/S)来对其进行建模:在分析阶段重点识别了问题域中的实体类,但只有实体类还不能使整个系统正常地运转起来,我们必须细化,为系统添加界面类和控制类。
2、组件设计(2种方法)图2:组件图(1)MainProgram图3:组件图(2)3、部署设计图4:部署图(二)、系统详细设计对用例的事件流进行梳理,逐一确定边界对象和实体对象,将边界对象放在界面层、实体对象和业务规则放在业务逻辑层,并根据流程确定接口;然后再根据业务逻辑层的实体类需要的数据存储来分析数据访问层;对分布式、并发、安全和日志等其他机制进行处理。
1、建立动态模型(1)对管理员“添加课程”行为进行分析“添加课程”用例的事件流如下:1)管理员选择进入登录界面,用例开始2)系统提示输入管理员密码3)管理员输入密码4)系统验证密码A1:密码错误5)进入管理界面,系统显示目前所建立的全部课程信息。
6)管理员选择添加课程7)系统提示输入新课程信息8)管理员输入信息9)系统验证是否和已有课程冲突A2:有冲突10)系统添加新课程,提示课程添加成功11)系统重新进入管理主界面,显示所有课程12)用例结束首先查找“添加课程”用例的对象,从事件流中发现涉及以下对象:(1)界面(2)课程(3)对于业务层的操作,也应该有对象进行处理。
(4)事件流中设计的角色有:管理员、数据库。
然后,分析对象、角色之间交互的消息。
本用例主要有以下交互:(1)管理员进入管理界面,选择添加课程功能(2)界面提示用户输入课程信息(3)界面对象创建一个课程对象(4)通过控制对象来对课程信息进行合法性检查(5)控制对象向课程对象返回结果(6)控制对象向数据库查询课程相关信息(7)控制对象对查询结果进行判断(8)控制对象向数据库中插入数据(9)在界面上显示结果(10)控制对象撤消建立的课程对象(2“选课”用例的事件流见“网上选课系统需求建模-1”首先查找“选课”用例的对象,从事件流中发现涉及以下对象:(1)界面(2)课程(3)对于业务层的操作,也应该有对象进行处理。
本文基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。
使用多重视图允许独立地处理各"风险承担人":最终用户、开发人员、系统工程师、项目经理等所关注的问题,并且能够独立地处理功能性和非功能性需求。
本文分别对五种视图进行了描述,并同时给出了捕获每种视图的表示方法。
这些视图使用以架构为中心的、场景驱动以及迭代开发过程来进行设计。
引言我们已经看到在许多文章和书籍中,作者欲使用单张视图来捕捉所有的系统架构要点。
通过仔细地观察这些图例中的方框和箭头,不难发现作者努力地在单一视图中表达超过其表达限度的蓝图。
方框是代表运行的程序吗?或者是代表源代码的程序块吗?或是物理计算机吗?或仅仅是逻辑功能的分组吗?箭头是表示编译时的依赖关系吗?或者是控制流吗?或是数据流吗?通常它代表了许多事物。
是否架构只需要单个的架构样式?有时软件架构的缺陷源于过早地划分软件或过分的强调软件开发的单个方面:数据工程、运行效率、开发策略和团队组织等。
有时架构并不能解决所有"客户"(或者说"风险承担人",USC 的命名)所关注的问题。
许多作者都提及了这个问题:Garlan & Shaw 1、CMU 的Abowd & Allen、SEI 的Clements。
作为补充,我们建议使用多个并发的视图来组织软件架构的描述,每个视图仅用来描述一个特定的所关注的方面的集合。
架构模型软件架构用来处理软件高层次结构的设计和实施。
它以精心选择的形式将若干结构元素进行装配,从而满足系统主要功能和性能需求,并满足其他非功能性需求,如可靠性、可伸缩性、可移植性和可用性。
Perry 和Wolfe 使用一个精确的公式来表达,该公式由Boehm 做了进一步修改:软件架构={元素,形式,关系/约束}软件架构涉及到抽象、分解和组合、风格和美学。
我们用由多个视图或视角组成的模型来描述它。
为了最终处理大型的、富有挑战性的架构,该模型包含五个主要的视图(请对照图1):•逻辑视图(Logical View),设计的对象模型(使用面向对象的设计方法时)。
uml建模网上选课系统UML统一建模语言第14章网上选课系统重点内容:需求分析创建系统用例模型创建系统静态模型创建系统动态模型创建系统部署模型UML统一建模语言一、需求分析网上选课系统是一个高等院校用来进行对学生选修课程管理的管理信息系统(MIS)。
该信息系统能够为学生提供方便的选课功能,也能够提高高等院校对学生和教学管理的效率。
网上选课系统的功能性需求包括以下内容:(1)系统管理员负责系统的管理维护工作,维护工作包括课程的添加、删除和修改,对学生基本信息的添加、修改、查询和删除。
(2)学生通过客户机浏览器根据学号和密码进入选课界面,在这里学生可以进行查询已选课程、指定自己的选修课程以及对自己基本信息的查询。
满足上述需求的系统主要包括以下几个小的系统模块:(1)基本业务处理模块。
基本业务处理模块主要用于实现学生通过合法认证登录到该系统中进行网上课程的选择和确定。
(2)信息查询模块。
信息查询模块主要用于实现学生对选课信息的查询和自身信息的查询。
(3)系统维护模块。
系统维护模块主要用于实现系统管理员对系统的管理和对数据库的维护,系统的管理包括学生信息、课程信息等信息的维护。
数据库的维护包括数据库的备份、恢复等数据库管理操作。
UML统一建模语言二、创建系统用例模型学生用例能够通过该系统进行如下活动:(1)查询选课信息。
学生可以在查询界面了解可供自己选择的各门课程的详细信息。
(2)登录选课系统。
学生能够根据自己的学号和密码登录选课系统,如果身份验证失败,不得进行下一步操作。
如果通过身份验证才能进入下一个操作界面。
(3)选择所修课程。
在选择课程的界面选择自己要选修的课程并确认提交。
(4)查询个人信息。
可以通过查询界面查询本人的基本信息。
UML统一建模语言二、创建系统用例模型系统管理员用例能够通过该系统进行如下活动:(1)登录选课系统。
系统管理员使用账号和登录密码登陆系统进行本系统的管理和维护工作。
(2)添加学生信息。
基于“4+1”视图的面向对象软件设计模型描述框架及其应用多年来,我们使用UML语言和Rose工具进行面向对象设计,使用SoDA工具生成设计文档。
在面向对象软件设计中,产生大量的类、接口、组件、包等模型元素,以及用例图、类图、活动图、序列图、状态图等UML图。
一些面向对象软件项目的模型元素和UML图多达几十至几百个,导致其UML设计模型难以组织和相应的设计文档难以编制,不可避免地遇到如何建立软件设计模型描述框架的技术问题。
为此,利用UML扩充机制提出了逻辑用例包、运行设计包、逻辑CSC、逻辑接口数据包等模型扩充描述要素,基于“4+1”视图体系结构和用例驱动方法建立了包含用例实现、软件进程、软件结构、外部/内部接口的设计模型描述框架,并利用该设计模型描述框架在Rose和SoDA工具上建立了UML设计模型模板和设计文档模板,实现了建模模板化和文档生成自动化。
1 软件设计模型描述框架“4+1”视图体系结构包括逻辑视图、进程视图、开发视图、物理视图和用例视图。
用例视图描述了软件需要的功能,并协调其他视图,保持设计的一致性,利用该视图可以建立软件用例实现模型。
逻辑视图描述了组成软件的若干类及其关系,利用该视图可以建立软件结构模型和接口设计模型。
进程视图描述了系统至进程和任务的分解以及这些并发元素之间的通讯和同步,利用该视图可以建立软件进程模型。
开发视图描述了在开发环境中软件的静态组织结构,利用该视图可以建立软件组件模型。
物理视图描述了物理网络的配置,软件至硬件的映射,通过软件设计建立软件部署模型。
这些模型共同构成软件设计模型。
我们用BNF其中,前四个模型一般均要用于软件设计建模,软件用例实现设计模型通过用例驱动方法与其它模型衔接,软件进程设计模型只用于多进程设计建模,软件部署设计模型只用于分布式软件设计建模。
以下针对各设计模型,进一步给出其描述框架。
(1) 软件用例实现设计子模型在软件设计过程中,每个用例均有相应的实现,可以用用例图表示相关用例和角色之间的关系,用序列图表示实现该用例的若干参与对象及其时序消息关系,用类图表示实现用例的这些参与对象所属类的相互关系,用活动图表示实现该用例的若干活动之间的关系,用状态图表示实现该用例的若干状态之间的转换关系。
软件体系结构描述报告案列一、用“4+1”视图模型分析某型号设备调试系统。
1.运用4+1视图方法从不同视图进行架构设计和软件描述逻辑视图:设计满足功能需求的架构开发视图:进行软件的管理和组织,如可通过程序库和子系统进行组织,设计满足开发期质量属性的架构进程视图:侧重系统的运行性能,设计满足运行期质量属性的架构物理视图:考虑如何把软件映射到硬件上,解决系统拓扑结构,系统安装和通信等(1)设备调试的逻辑视图(2)开发视图:设计满足开发期质量属性的体系结构(3)处理视图:设计满足运行期质量属性的体系结构(4)物理视图:(5)设备调试系统的场景图:案列二、云计算体系结构(1)云计算的体系结构由5部分组成,分别为应用层、平台层、资源层、用户访问层和管理层,云计算的本质是通过网络提供服务,所以其体系结构以服务为中心(2)云是一个由并行的网络所组成的巨大服务网络,它通过虚拟化技术来扩展云端的计算能力,以使得各个设备发挥最大的效能。
数据的处理及存储均通过云端的服务器集群来完成,这些集群由大量普通的工业标准服务器组成,并由一个大型的数据处理中心负责管理,数据中心按客户的需要分配计算资源,达到与超级计算机同样的效果。
(3)云计算结构包括:资源池层是指基础架构屋面的云计算服务,这些服务可以提供虚拟化的资源,从而隐藏物理资源的复杂性。
物理资源指的是物理设备,如服务器等。
服务器服务指的是操作系统的环境,如linux集群等。
网络服务指的是提供的网络处理能力,如防火墙,VLAN,负载等。
存储服务为用户提供存储能力。
平台层为用户提供对资源层服务的封装,使用户可以构建自己的应用。
数据库服务提供可扩展的数据库处理的能力。
中间件服务为用户提供可扩展的消息中间件或事务处理中间件等服务。
应用层提供软件服务企业应用是指面向企业的用户,如财务管理,客户关系管理,商业智能等。
个人应用指面向个人用户的服务,如电子邮件,文本处理,个人信息存储等。
用户访问层是方便用户使用云计算服务所需的各种支撑服务,针对每个层次的云计算服务都需要提供相应的访问接口。
利用“4+1”视图建模方法进行“网上选课系统”软件体系结构设计所学专业:软件工程年级班级: 2010级软工-2 班所属小组:第六组组负责人:耿奇云组内成员:耿奇云郜振南杨建威成员学号: 1010107041 1010107040 1010107054河南农业大学信息与管理科学学院2012年12月19日一、引言(一)运用4+1视图方法:针对不同需求进行架构设计要开发出用户满意的软件并不是件容易的事,软件架构师必须全面把握各种各样的需求、权衡需求之间有可能的矛盾之处,分门别类地将不同需求一一满足。
Philippe Kruchten提出的4+1视图方法为软件架构师"一一征服需求"提供了良好基础,如图1示。
图1运用4+1视图方法针对不同需求进行架构设计场景视图:场景视图关注案例描述,即对案软件需求的功能描述和非功能描述;对应于UML建模中的用例建模。
逻辑视图:逻辑视图关注功能,不仅包括用户可见的功能,还包括为实现用户功能而必须提供的"辅助功能模块";它们可能是逻辑层、功能模块等。
开发视图:开发视图关注程序包,不仅包括要编写的源程序,还包括可以直接使用的第三方SDK和现成框架、类库,以及开发的系统将运行于其上的系统软件或中间件。
开发视图和逻辑视图之间可能存在一定的映射关系:比如逻辑层一般会映射到多个程序包等。
处理视图:处理视图关注进程、线程、对象等运行时概念,以及相关的并发、同步、通信等问题。
处理视图和开发视图的关系:开发视图一般偏重程序包在编译时期的静态依赖关系,而这些程序运行起来之后会表现为对象、线程、进程,处理视图比较关注的正是这些运行时单元的交互问题。
物理视图:物理视图关注"目标程序及其依赖的运行库和系统软件"最终如何安装或部署到物理机器,以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。
物理视图和处理视图的关系:处理视图特别关注目标程序的动态执行情况,而物理视图重视目标程序的静态位置问题;物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。
(二)软件需求分类需要架构设计的多重视图方法,从根本上来说是因为需求种类的复杂性所致。
软件需求包括功能需求和非功能需求。
非功能需求包括质量属性和约束条件。
质量属性包括运行期质量属性和开发期质量属性。
软件需求分类如图2所示。
图2 软件需求分类(三)网上选课需求1.网上选课系统需求描述管理员通过系统管理界面进入,建立本学期要开设的各门课程,并将课程信息保存到数据库中,并可以对课程进行一定的改动和删除操作。
学生通过浏览器可以查询已选课程信息并进行选课,教师可以选择所要上的课程并提交所选课程的成绩。
管理员同时负责维护各项信息。
以上信息统一保存到数据库中。
2.网上选课系统需求表1 网上选课系统:需求种类分析二、网上选课系统场景建模场景视图:场景视图关注案例描述,即对案软件需求的功能描述和非功能描述;对应于UML建模中的用例建模。
(一)用例建模与分析步骤根据网上选课系统需求概述进行用例建模与分析。
用例建模与分析步骤如图3示。
1.确定网上选课系统的边界范围,找出系统外部的参与者和外部系统2.确定各个参与者应有的系统行为,并命名为用例3. 把系统中公共的系统行为分解为新的用例,供其它用例引用4. 把系统中一些变更的行为分解为扩展用例5. 编制用例的脚本6. 绘制系统的用例图7. 把系统用例中特殊情况的用例画成单独的子用例图(二)用例建模具体过程1.确定系统边界范围,找出参与者系统参与者包括:管理员、学生和老师管理员学生老师系统图42.确定每一个参与者所希望的系统行为管理员:登陆、课程管理、学生管理和老师管理学生:登录、选课、查询课程老师:登录、查询课程、提交成绩图53. 把公共系统行为分解为新的用例将管理员、学生和老师的登陆抽取为公共用例;管理员学生系统老师课程管理学生管理登录老师管理查询课程提交成绩选课<<uses>><<uses>><<uses>><<uses>><<uses>><<uses>><<uses>><<uses>><<uses>><<uses>>图64. 扩展用例将所有操作保存的用例扩展为数据库。
图75.用例图优化抽取用户角色,实现统一登录;抽取课程管理用例,与学生信息管理、教师信息管理等用例并列图86.用自然语言和事件流编写网上选课用例脚本(1)用户登陆脚本:1)运行程序,弹出登录界面;2)在登陆界面输入用户名、密码和用户类型;3)提交信息进行验证;A1:用户信息验证异常4)进入操作界面。
A1:用户信息验证异常3a)提示用户用户名或密码或用户类型错误3b)重新输入用户名、密码和用户类型3c)转到3)老师的选课脚本:一、(1)运行程序,弹出登陆界面,(2)在登陆界面输入用户名、密码和用户类型;(3)提交信息进行验证;A:用户信息验证异常(4)进入操作界面。
A:用户信息验证异常1、提示用户用户名或密码或用户类型错误2、重新输入用户名、密码和用户类型3、转到(3)二、(1)登陆成功后,在选课界面进行选课;(2)选择课程,单击完成,系统进行验证;A1:课程信息异常,重新进行选课;(3)选课成功;(4)退出程序;老师的提交成绩脚本如下:(1)用户登陆界面后输入用户名、密码和用户类型;(2)提交信息进行验证:如果信息异常系统将退出,用户需重新登陆(3)用户登陆成功后进入学生成绩界面,并提交学生的成绩,因此显示选课学生的姓名、学号、班级、成绩;(4)系统确认输入的信息完整没有缺失或错误;(5)系统将输入的学生成绩存储建档;(6)用户提交成绩成功后退出程序。
若提交失败将退回(3);学生的选课教本:(1)用户登陆界面后输入用户名、密码和用户类型;(2)提交信息进行验证:如果信息异常系统将退出,用户需重新登陆(3)用户登陆失败将返回(1),登陆成功后进入学生选课系统;(4)学生选择所要选择的课程后提交,系统将确认改门课程是否已满;A:若所选课程人数已满,选课失败,返回(3)重新选课;若选课成功,则系统将会把改课程添加到学生的课程表里;(5)用户退出程序;学生的查询课程教本:(1)用户登陆界面后输入用户名、密码和用户类型;(2)提交信息进行验证:如果信息异常系统将退出,用户需重新登陆;(3)用户登陆失败将返回(1),登陆成功后进入学生主页查询课程;(4)用户退出程序管理员的教师信息教本:(1)用户登陆界面后输入用户名、密码和用户类型;(2)提交信息进行验证:如果信息异常系统将退出,用户需重新登陆;(3)用户登陆失败将返回(1),登陆成功后进入管理员主页;(4)管理员在主页上进行教师的信息管理操作;(5)用户推出程序;管理员的教师信息教本:(1)用户登陆界面后输入用户名、密码和用户类型;(2)提交信息进行验证:如果信息异常系统将退出,用户需重新登陆;(3)用户登陆失败将返回(1),登陆成功后进入管理员主页;(4)管理员在主页上进行学生的信息管理操作;(5)用户推出程序;管理员的教师信息教本:(1)用户登陆界面后输入用户名、密码和用户类型;(2)提交信息进行验证:如果信息异常系统将退出,用户需重新登陆;(3)用户登陆失败将返回(1),登陆成功后进入管理员主页;(4)管理员在主页上进行课程管理界面进行相应的操作;(5)用户推出程序;7.绘制用例图根据分析与描述,本网上选课系统的用例图如下图10三、网上选课系统逻辑视图逻辑视图:逻辑视图对应于功能需求,设计满足功能需求的架构。
逻辑视图关注功能,不仅包括用户可见的功能,还包括为实现用户功能而必须提供的"辅助功能模块";它们可能是逻辑层、功能模块等。
首先根据功能需求进行初步设计,进行大粒度的职责划分。
根据用例描述,将系统划分为6层,如图?所示。
图?网上选课系统架构的逻辑视图四、网上选课系统开发视图开发视图:开发视图对应于开发期质量属性,设计满足开发期质量属性的架构,包括扩展性、可重用性、可移植性、易理解性和易测试性等。
开发视图关注程序包,不仅包括要编写的源程序,还包括可以直接使用的第三方SDK和现成框架、类库,以及开发的系统将运行于其上的系统软件或中间件。
开发视图和逻辑视图之间可能存在一定的映射关系:比如逻辑层一般会映射到多个程序包等。
软件架构的开发视图应当为开发人员提供切实的指导。
任何影响全局的设计决策都应由架构设计来完成,这些决策如果"漏"到了后边,最终到了大规模并行开发阶段才发现,可能造成"程序员碰头儿临时决定"的情况大量出现,软件质量必然将下降甚至导致项目失败。
其中,采用哪些现成框架、哪些第三方SDK、乃至哪些中间件平台,都应该考虑是否由软件架构的开发视图确定下来。
图*展示了网上选课系统的(一部分)软件架构开发视图:数据库层持久层与连通层(DAO)商务逻辑层会话层表示层应用层StrutsSpringHibernate图* 网上选课系统架构的开发视图在说说约束性需求。
约束应该是每个架构视图都应该关注和遵守的一些设计限制。
例如,考虑到"一部分开发人员没有嵌入式开发经验"这条约束情况,架构师有必要明确说明系统的目标程序是如何编译而来的:图**展示了整个系统的桌面部分的目标程序pc-moduel.exe 、以及嵌入式模块rom-module.hex 是如何编译而来的。
这个全局性的描述无疑对没有经验的开发人员提供了实感,利于更全面地理解系统的软件架构。
图** 网上选课系统架构的开发视图五、网上选课系统过程视图处理视图:处理视图,即过程视图,设计满足运行期质量属性的架构,对应于运行期质量属性,包括易用性、性能、可伸缩性、持续可用性、鲁棒性和安全性等。
处理视图关注进程、线程、对象等运行时概念,以及相关的并发、同步、通信等问题。
处理视图和开发视图的关系:开发视图一般偏重程序包在编译时期的静态依赖关系,而这些程序运行起来之后会表现为对象、线程、进程,处理视图比较关注的正是这些运行时单元的交互问题。
性能是软件系统运行期间所表现出的一种质量水平,一般用系统响应时间和系统吞吐量来衡量。
为了达到高性能的要求,软件架构师应当针对软件的运行时情况进行分析与设计,这就是我们所谓的软件架构的处理视图的目标。
处理视图关注进程、线程、对象等运行时概念,以及相关的并发、同步、通信等问题。
图展示了网上选课系统架构的处理视图。