软件设计与体系结构实验报告
专业班级： 计算机1101
姓 名：
学 号： 12
指导教师： 王超学
实验一 熟悉开发绘图工具Visio软件的使用方法
班级：计算机1101 姓名：学号： 12 指导老师： 王超学
评分：
一．实验目的
熟悉开发绘图工具Microsoft Visio软件的使用方法；
二．实验设备
计算机、Microsoft Visio软件。
三． 实验内容及步骤
实验内容：
1．熟悉开发绘图工具Microsoft Visio软件的工作环境和基本使用方法。
2．练习软件设计中常用的流程图、数据流图、用例图、序列图、类图、组件图、部署图的绘制。
实验步骤：
在启动操作系统（如Windows2000）之后，启动Microsoft Visio软件。
利用软件中的入门教程进行学习。
3、进入Visio的UML建模绘图界面
通过“开始”|“程序”，运行Microsoft Office Visio 2007，出现Microsoft Visio界面。
方法一：
在左侧的“类别”区域中单击“软件和数据库”，然后在右侧的“特色模板”中单击“UML模型图”，则进入Visio的UML建模绘图界面。
模板类别
特色模板
方法二：
单击菜单“文件”| “新建”| “软件和数据库”| “UML模型图”。
4、熟悉UML建模绘图界面
在Visio的UML建模绘图界面中，最大的白色区域就是绘图区。左上方的“形状”窗口就是Visio的UML元素调板，它由很多的标签页组成。每个标签页提供了一个特定的UML图标。左下方的“模型资源管理器”就是Visio的字典，字典就是所创建的所有元素及其属性的记录的集合。当Visio打开并准备开始UML绘图的时候，“UML静态结构”标签页就会激活，我们就可以创建UML模型（如类图、对象图、包图、用例图、交互图、活动图等等）。
UML建模绘图界面
“形状”窗口
“模型资源管理器”
绘图区
5．练习流程图、数据流图、用例图、序列图、类图、组件图、部署图的绘制。
四、实验结果
（1）用例图、序列图、类图、组件图、部署图的选择界面
（2）用例图、序列图、类图、组件图、部署图的绘图界面
（3）数据流图的绘图界面
（4）流程图的绘图界面
五、实验小结
以前就接触过visio画图软件，但不是特别熟悉，通过本次实验的练习，基本掌握了对流程图、数据流图、用例图、序列图、类图、组件图、部署图的绘制。熟悉visio绘图软件的基本使用方法，
做实验期间遇到了一些画图问题，通过问老师和同学解决。在实验的过程中，通过逐一实验掌握各种工具的使用，对熟练掌握此软件的使用也有了一定的基础。
实验二 使用UML进行系统建模
班级：计算机1101 姓名：学号：指导老师：王超学
评分：
一．实验目的
针对指定软件系统的需求进行分析和设计；
使用Microsoft Visio软件，绘制UML图。
二．实验设备
计算机、Microsoft Visio软件。
三．实验内容及步骤
案例：银行ATM自动柜员机的需求简述
本案例将要开发的ATM系统能够为顾客提供以下基本服务（它们统一称为交易）：
(1)取款服务。顾客可以用银行卡从对应的账户中支取现金，现金必须是100元的整数倍，且每次取款不能超过2000元。
(2)存款服务。顾客可以把现金存入与银行卡对应的账户中。
(3)转帐服务。顾客可以把一个银行卡对应的账户中的款项转帐到另一个银行账户中。
(4)查询服务。顾客能够查询一个银行卡对应的账户中的余额。
该ATM系统包括以下组成部分：
(1)能够读取银行卡信息的读卡器。
(2)与客户进行交互的顾客控制台（包括键盘和显示器）。
(3)送出顾客所取现金的装置（下文中称为取款器）。
(4)用于放入存款的插槽（下文中称为存款器）。
(5)打印客户回执的打印机。
(6)启动和关闭ATM系统的开关键盘。
(7) ATM系统与银行服务器通过特定的网络连接进行通信。
ATM系统在提供以上服务的过程中，必须满足以下要求：
(1)一个顾客可以在最终确认前放弃一项交易。
(2)ATM在执行交易过程中将与银行系统进行通信，对是否允许交易进行验证。
(3)ATM为每次成功的交易提供一个打印回执。
(4)ATM需要维护一个内部日志，对每次交易进行记录。
在获取待开发系统的业务需求描述后，对ATM机系统进行建模，按照下列要求完成实验内容：
（a）画出细化后的用例图、取款用例的序列图；
（b）画出系统的分析类图；
（c）画出系统的顶层架构；
（d）画出“用户交互层”包精华后的模型及其子包精华后的模型；
（e）画出系统的部署模型；
四、实验结果
细化后的用例图
取款用例的序列图
系统的分析类图
系统的顶层架构
五、实验小结
通过这次试验的学习，使得我对visio软件的使用更进一步的熟练，也使得自己对软件开发设计这一阶段所应掌握的各种流程图有了更清晰地认识，实验期间遇到了有些控件找不到，通过上网搜索和问老师同学，将问题解决了。这使我意识到，课前应该预习，否则上课的时候还是会遇到很多问题。希望这对以后独自再去设计一个软件的时候有很大的帮助，对软件的设计也有了近一步的了解，也学到一些在对一个软件设计时进行分析的方法，使用各种流图更清楚的表达出自己的设计思路，这对我以后在这方面的学习也有了很大的帮助。
第二篇：软件设计模式实验报告xx
应用4+1视图法及UML设计软件体系架构及设计模式实践
一 实验目的
通过对实际案例进行软件设计来掌握软件体系架构模式的选择应用以及典型4+1视图软件架构设计方法的应用，并能熟练掌握如何利用Rational Rose软件进行软件架构设计。
二 实验内容
(1) 根据“信用卡申请件处理外包业务处理平台设计”需求选定软件体系结构模式
(2) 利用UML软件进行4+1视图架构设计，包括逻辑视图、开发视图、进程视图、物理视图和场景视图。’
A 逻辑视图描述系统的功能需求，系统分解成一系列的功能抽象，采用时序图、协作图、类图等来表示；
B 开发视图描述软件在开发环境下的静态组织。开发视图关注程序包，应用的统一框架，引用的类库、SDK和中间件，以及工程和包的划分规则等，规范、约束开发环境的结构；
C 进程试图侧重系统的运行特性，关注非功能性的需求（性能，可用性）。服务于系统集成人员，方便后续性能测试。强调并发性、分布性、集成性、鲁棒性（容错）、可扩充性、吞吐量等。定义逻辑视图中的各个类的具体操作是在哪一个进程和线程中被执行，可以组件图为基础表示；
D 物理试图主要描述硬件配置。服务于系统工程人员，解决系统的拓扑结构、系统安装、通信等问题。主要考虑如何把软件映射到硬件上，也要考虑系统性能、规模、可靠性等。可以与进程视图一起映射；
E 场景用于刻画构件之间的相互关系，将四个视图有机地联系起来。
可以描述一个特定的视图内的构件关系，也可以描述不同视图间的
构件关系。通常用Use Case图来描述。
(3) 设计模式的实践，从创建者模式、结构型模式和行为模式三大类模式进
行对象设计，每种类型的模式至少应用一种，并用应用了设计模式后的类设计修订逻辑视图中的类图。
三 SOA架构模式及流程分析（湛滨瑜）
3.1 SOA架构介绍 SOA是英文Service-Oriented Architecture，即面向服务架构的缩写。
面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。
对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。
SOA三大基本特征
1、独立的功能实体
在Internet这样松散的使用环境中，任何访问请求都有可能出错，因此任何企图通过Internet进行控制的结构都会面临严重的稳定性问题。 SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术，如.NET Remoting，EJB，COM或者CORBA，都需要有一个宿主 (Host或者Server)来存放和管理这些功能实体；当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问 题的时候，在该宿主上运行的其它应用服务就会受到影响。
SOA架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如事务处理(Transaction)，消息队列(Message Queue) ，冗余部署(Redundant Deployment)和集群系统(Cluster)在SOA中都起到至关重要的作用。
2、大数据量低频率访问
对于.NET Remoting，EJB或者XML-RPC这些传统的分布式计算模型而言，他们的服务提供都是通过函数调用的方式进行的，一个功能的完成 往往需要通过客户端和服务器来回很多次函数调用才能完成。在Intranet的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽 略不计，但是在Internet环境下这些因素往往是决定整个系统是否能正常工作的一个关键决定因素。因此SOA系统推荐采用大数据量的方式一次 性进行信息交换。
3、基于文本的消息传递
由于Internet中大量异构系统的存在决定了SOA系统必须采用基于文本而非二进制的消息传递方式。在COM、CORBA这些传统的组件模型中， 从服务器端传往客户端的是一个二进制编码的对象，在客户端通过调用这个对象的方法来完成某些功能；但是在Internet环境下，不同语言， 不同平台对数据、甚至是一些基本数据类型定义不同，给不同的服务之间传递对象带来的很大困难。由于基于文本的消息本身是不包含任何处 理逻辑和数据类型的，因此服务间只传递文本，对数据的处理依赖于接收端的方式可以帮忙绕过兼容性这个的大泥坑。
3.2信用卡申请件外包处理流程分析
信用卡申请件外包处理的主要流程为：
第一阶段：
信用卡申请人准备个人档案资料并接件提交，将所有接受的档案文件通过拆件、然后再分类整理后，给申请人的档案资料帖上条形码标识。在影像处理过程中，通过电子扫描设备将档案条形码扫人，经过对档案文件的质量检测和影像的切分后将数据信息传输给外包中心做数据处理。
第二阶段：
外包中心接受到影像处理阶段传递的数据信息后，通过任务分配环节将传递过来的数据信息录入，两次录入完成后，进入一个重要的复核环节。如果复核匹配失败，则进入第三人复核阶段，如果第三人复核成功，在确保数据录入的准确无误后进入影像匹配阶段。如果第三人复核失败，则将问题交由专门的人员来处理解决。通过影像匹配环节将数据归档处理。供工作人员查询使用。同时将数据回传递给银行信用卡数据中心。
第三阶段：
银行信用卡数据中心，接受到数据，并保存。
四 4+1视图（张献忠）和设计模式（李金栓）
4.1 4+1视图介绍
软件架构用来处理软件高层次结构的设计和实施。它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。Perry 和 Wolfe 使用一个精确的公式来表达，该公式由 Boehm 做了进一步修改：
软件架构 ＝ {元素，形式，关系/约束}
软件架构涉及到抽象、分解和组合、风格和美学。我们用由多个视图或视角组成的模型来描述它。为了最终处理大型的、富有挑战性的架构，该模型包含五个主要的视图
逻辑视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。
过程视图（Process View），捕捉设计的并发和同步特征。
物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。
开发视图（Development View），描述了在开发环境中软件的静态组织结构。
架构的描述，即所做的各种决定，可以围绕着这四个视图来组织，然后由一些用例 （use cases）或场景(scenarios)来说明，从而形成了第五个视图。正如将看到的，实际上软件架构部分从这些场景演进而来，我们在每个视图上均独立地应用 Perry & Wolf 的公式，即定义一个所使用的元素集合（组件、容器、连接符），捕获工作形式和模式，并且捕获关系及约束，将架构与某些需求连接起来。每种视图使用自身所特有的表示法－蓝图（blueprint）来描述，并且架构师可以对每种视图选用特定的架构风格（architectural style），从而允许系统中多种风格并存。
我们将轮流的观察这五种视图，展现各个视图的目标：即视图的所关注的问题，相应的架构蓝图的标记方式，描述和管理蓝图的工具。并以非常简单的形式从 PABX 的设计中，从我们在Alcatel 商业系统（Alcatel Business System）上所做的工作中，以及从航空运输控制系统（Air Traffic Control system）中引出一些例子―旨在描述一下视图的特定及其标记的方式，而不是定义这些系统的架构。
"4+1"视图模型具有相当的"普遍性"，因此可以使用其他的标注方法和工具，也可以采用其他的设计方法，特别是对于逻辑和过程的分解。但文中指出的这些方法都已经成功的在实践中运用过。
4.2设计模式介绍
4.3创建者模式
4.4结构型模式
4.5行为模式
五 逻辑试图（罗创） 逻辑试图介绍
5.1用例图
5.2时序图
5.3状态图
5.4类图（李金栓）
5.5。。。
六 开发视图（罗创）
七 进程视图
八 物理视图（李金栓）
九 场景视图