【文档说明】软件体系结构设计案例分析课件.ppt，共(55)页，1.275 MB，由小橙橙上传

转载请保留链接：https://www.ichengzhen.cn/view-2523.html

以下为本文档部分文字说明：

软件体系结构设计案例体系结构设计案例◼科学数据共享网◼空中交通管制科学数据共享网体系结构设计科学数据共享网科学数据共享网的系统需求◼“中国地球系统科学数据共享网”是国家科学数据共享工程的重要组成部分，同时也是科技部推动“国家科学数据共享工程”2002年试

点的三个科学数据共享网之一。◼该系统针对基于各圈层（大气圈、水圈、生物圈）相互作用的地球系统科学的整体研究，利用互联网，整合、集成各科研院所、高等院校和国际数据组织以及科学家个人手中的相关专业数据资源，瞄准地球系统科学的前沿研

究，开展数据组织、加工与服务，构建物理上分布、逻辑上统一的地球系统科学数据管理与共享服务网。这一工作对于增强我国基础科学研究和前沿科学创新能力具有重要的意义。数据方面的特殊需求和特点◼能够快捷地收集数据◼科学数据分散在科研院所和科学家手中，要设计开发一套收集数据的机制，使其能够快速地整合到系统中，

提供数据共享服务。◼数据收集的途径应主要通过网络媒介，而且不能影响系统所提供的网络服务的正常运行。◼有效存储和管理海量数据，并快速定位数据◼该系统能够提供目录服务，合理地管理数据。◼提供用户查阅、下载、使用数据的服务。◼当用户在系统中查找数据时，希望能够快速定位数据，提供服务，平

均响应时间最长不超过20秒。数据方面的特殊需求和特点◼保护数据版权，保证数据的安全性◼科学数据是科学工作者辛勤劳动的果实，同书籍一样也存在版权的问题。所以在数据的使用上，需要版权保护。◼此外，由于一些数据有

其时效性和保密性，所以在提供服务时需要对数据访问进行相应的安全控制。系统需求◼架构师一般通过两种途径来获得系统的需求：◼用户直接主动地提供的需求（一般都是功能性需求和领域知识）◼希望“科学数据共享网”能通过Internet为用户提供数据服务，包含：数据目录服务

、数据资源导航、数据下载功能、对数据进行稳妥地安全管理。◼构架师设计“对话问题”，通过对用户提问，进一步与他们沟通，从而得到明确的需求。◼构架师以用软件系统各方面的质量属性为索引，系统地启发用户谈出他们实际需要、但没

有表达出来或是表达不完全的内容。非功能性需求质量属性针对质量属性的需求可用性/可靠性系统应能长期稳定地提供服务，近似7×24小时工作强度；在负载过重或是系统崩溃的情况下，能保证用户的请求不丢失；当系统出现故障或崩溃时，恢复时间不超过两小时；可维护性修改某个子系统或服务时，不影响其他子系统或

服务；性能高峰时系统的平均响应时间控制在20秒以内；系统能够满足100个并发的用户查询请求；系统至少能够支持2000个用户的在线服务；安全性对有保密性要求的数据实施安全控制；提供系统运行日志监控信息，供管理员了解系统的运行和安全状态；

商业属性2005年中期完成系统，年底前投入正式使用；能够利用现有系统的可利用资源；初期总共投资2000万，分别用于系统的集成建设和开发、共享数据标准的制定。◼科学数据共享网的体系结构？科学数据共享网的体系结构◼原型的体系结构及其分析◼根据需求，数据将以Internet为传输途径

完成共享。在目前以Internet为前提的系统中，应用最广泛的是B/S（Browser/Server）结构。◼这样的结构已经相当成熟，并具有很大的灵活性。科学数据共享网也是基于这样初衷而设计的。系统的原型设计系统的原型设计◼对于科学数据的存储、管理、共享等诸多计算都是由“中心”服

务器承担。在中心服务器中，又划分了数据收集、数据访问、平台数据管理和平台管理四个模块。◼数据收集负责收集用户通过Internet上载或是其它途径（光盘、磁盘）提交上来的科学数据。◼数据访问负责向用户提供访问科

学数据的服务---查询和下载◼平台数据管理承担了与数据库交互，管理和存储数据的工作。它提供的接口负责将收集的科学数据先暂存在平台数据库中；然后供工作人员对数据进行有效性检查和加工，并将合法数据转移到发布数据库中；最后管理发布数据库中数据的接口提供数据的访问服务。◼平台管理承担了管理用户信息、管理用

户和数据的安全信息，以及生成平台运行日志的任务。◼是否合适？对原型系统的分析◼所有的数据都由“中心”服务器负责存储，并向用户提供服务。◼这样的结果是所有的用户请求都由中心服务器来响应。即使内部的四个模块部署到

不同的服务器上，“平台数据管理”和两个数据库所承担的运算量也是可观的。◼考虑到未来的科学数据将会越来越庞大，大量的数据都存储到服务器中，对服务器来讲必然是巨大的负担。而且，数据管理和维护的成本也随着数据

量的增加而加大。◼“中心”服务器承载了众多服务，因而其运算量会很繁重；因此为了达到性能方面的要求，对“中心”服务器的要求就会比较高，比如：增加内存容量，CPU数量。这也增加了系统的投入成本。有时，仅仅通过提高服务器的性能是不能够达到性能方面要求的。对原型系统的分析◼请求都由“中心”服务

器做出响应，一旦它出现了故障，无法提供服务，则存储在系统中的科学数据就无法向外界提供共享服务。◼补救办法：增加备份服务器，组成集群◼当系统升级时，也会对所提供的服务造成影响。◼客户要求尽量达到7×24小时服务，平均修复时间不超过2小时。实现客户要求相当难度，成本也

高。◼数据都存储在一个系统内，采取了通过Internet上载或是其它途径（光盘、磁盘等方式）提交科学数据的方式。考虑到地学领域的数据通常是较大的地图，网络提交数据的方式会影响到“中心”服务器的数据吞吐量，降低了系

统性能。重新设计的面向服务的体系结构体系结构说明◼面向服务的体系结构◼门户（主数据中心），安全中心和分数据中心通过由WebService构建的数据共享服务、全局服务、安全服务相互连接，组成了科学数据共享网的体系结构。◼新的体系结构划分了主数据中心、分数据中心和安全中心；三

类中心分别有各自基于B/S结构的管理系统，相对独立。◼遵循面向服务的体系结构思想，为了实现数据的共享服务，各个中心将服务内容封装成WebService，作为其他中心访问本中心数据的入口，并通过Internet传输数据。◼SOAP提供

一种简单的、可扩展并且功能丰富的XML消息处理框架，用于定义高级别的应用程序协议，从而在分布式异构环境中提供更高的互操作性。体系结构说明◼在该系统中，科学数据存储在各个数据中心上；各分数据中心通过数据服务的Webservice组件向主数据中心公布其元数据信息，作

为实现数据共享的基础（元数据是描述数据的数据）。◼通过在主数据中心上查找元数据信息，可以快速地获取科学数据的消息信息，定位数据访问入口-----某个分数据中心的数据共享服务，然后实现数据的访问。体系结构说明◼主数据中心作为整个系统共享服务的一个入口，它提供了查询主数据中

心上元数据信息的服务；负责向分数据中心转发用户访问科学数据的请求。◼分数据中心也可以作为共享服务的入口。每个分数据中心都具有各自的管理信息系统，收集和管理某个研究领域内的科学数据，用户可以直接登录某个分数据中心上访问数据。◼加入了安全

中心。用户的基本信息，如密码、住址、所属单位等，都由安全中心保存和维护。安全中心为所有数据中心提供了用户的身份验证、维护的安全服务。◼但是用户访问数据的权限则由各个数据中心独立地设置和管理。各中心的信息存储结构数据中心的分层体系结构数据中心

的分层体系结构◼分层体系结构：某一层功能和实现的变化只是上下层有关（低耦合，可扩展、组件复用）◼安全管理：访问权限◼日志管理：多种操作的记录◼数据访问层：审查、发布数据的操作◼应用服务层：多个共享服务组件◼共享服务接口：访问接口、入口，重用部分应

用服务组件◼主数据中心:全局服务◼分服务中心：数据收割（为主数据中心收集元信息）◼注意连接件设计p133安全中心的体系结构体系结构分析◼面向服务的体系结构是一种松耦合、协议和实现独立的体系结构；松耦合与随需应变是SOA的两大特点。◼采用这种体系结构，可以重用已有系统作为

分数据中心；允许异构数据的存在和访问；并且能够给系统带来良好的可维护性和可扩展性。◼新的系统中，最主要的一点变化就是：科学数据将不再统一由“中心”服务器存储和管理，改为由数据所有者（科研工作者或是科研院所）负责存储和管理。数据共享网可维护性解决策略◼在科学数据共享网系统中，

在不同的层次设计中分别采用了“间接化、封装、分离”。◼首先，整个系统的分布式体系结构设计，采用了SOA的体系结构设计，这种设计是将数据共享服务封装为WebService，由特定的WebService提供数据共享服务。WebService的引入，将共享数据内容和共享服务实现

细节分离。当实现细节发生变化或是增加新的服务时，对原有系统的运行影响很小。◼在数据中心和安全中心的系统设计上，采用了分层的设计。这是一种间接化的体系结构设计策略，上层的共享服务需要通过数据访问层提供的接口访问数据；当底层数

据存储结构变化后，对上层的共享服务的影响较小。◼数据中心和安全中心的web应用系统采用的是MVC模式，将模型、控制、视图有机地分离。空中交通管制http://etutorials.org/Programming/Software+architecture+in+p

ractice,+second+edition/Part+Two+Creating+an+Architecture/Chapter+6.+Air+Traffic+Control+A+Case+Study+in+Designing+for+High+Availability/系统概况系统概况◼

飞机从顺利起飞到安全到达目的地，受到空中交通管制系统各个不同部分的管理。◼地面控制部分负责协调和管理飞机在机场地面上的运动；◼塔台控制部分控制飞机在该机场的终端控制区中的飞行；◼最后，该系统还有多个中途中心，将整个美国领空划分为22个责任区

。初始区段组（InitialSectorSuiteSystem，ISSS）ISSS是针对22个中途中心的软硬件升级系统需求与质量分析◼空中交通管制系统若运行不好，可能会造成生命财产损失◼极高的可用性◼必须保证系统不能正常工作

的时间非常短（一年内停机时间不能超过5分钟）◼高性能◼系统必须保证在不丢失任何数据的情况下对大量数据进行处理；◼通信网络必须能够处理这种负载，软件必须能够快速、带有预测性的进行计算。ISSS的功能◼获取存储在主计算机系统

的现有空中交通管制系统中的雷达目标数据◼转换雷达数据以供显示，并将其广播给所有控制台。每个控制台选择自己需要显示的报告数据，每个控制台都能够显示任何方位的数据◼处理冲突警告，或其它由主计算机发送来的数

据◼提供与主计算机的接口，以便于输入和查询飞行计划◼提供诸如网络管理等多方面的监控信息，允许场站管理员实时地重新配置所安装的系统◼提供记录能力，以供事后回放◼在控制台上提供如窗口形式的图形用户界面，有必要提供特殊的与安全相关的功能，如显示

的窗口有一定的透明度，以免遮挡住重要信息◼在主计算机、主要的通信网络以及主要的雷达传感器出现故障时，提供一定的后备能力ISSS系统所处的物理环境主计算机负责对监控数据和飞行计划数据进行处理通用控制台空中交通管制人员的工作站；一个区段组可

以有1~4台通用控制台通用控制台通用控制台通用控制台本地通信网络（LCN）双LCN接口单元与LCN相连4个并行令牌环网增强直接访问雷达信道BCN监控控制台监控控制台测试培训子系统外部系统接口（ESI）物理视图模块分解视图显示管理通用系统服务记录、分析与回放全国空域系统修

改操作系统捕获交通管制系统中的会话，以备事后分析进程视图◼ISSS系统按照多处理器的环境设计。这些处理器在逻辑上组成处理器组。处理器组的目的是要分别运行一个或多个应用程序的副本。其中，一个为主，其他为辅，称统一应用程

序及其不同副本为主地址空间（PAS）和备用地址空间（SAS）。◼操作单元：一个主地址空间和与其相应的备用地址空间的集合称为操作单元。◼功能组：未以容错方式实现的ISSS系统的其他部分在不同的处理器上独立运行，称其为功能组。进程视图添加一

个新的操作单元的步骤◼如果在SAS内部发现了错误，就要在另外的处理器上启动新的SAS。新的SAS要与其PAS协调工作，并接收状态数据。◼确定必要的输入数据及所在的位置；◼确定哪些操作单元需要用到该新操作单元的输出数据；◼以一种使该图仍然保持非循环的方式将该操作单元的通信模

式加到整个系统的非循环通信图中，以免发生死锁；◼设计消息，实现所期望的数据流；◼确定在进行系统评审时必须要用到的内部状态数据，以及在从PAS到SAS的更新通信中必须包括的状态数据；◼将状态数据划分为能够很好地适应网络要求的消息；添加一

个新的操作单元的步骤◼如果在SAS内部发现了错误，就要在另外的处理器上启动新的SAS。新的SAS要与其PAS协调工作，并接收状态数据。◼定义必须用到的消息类型；◼规划在PAS失败时的切换：要对更新数据做合理的规划，保证能够完全反映出各种状态；◼保证

在切换发生时数据的一致性；◼保证各个处理步骤能够在不超过一次系统“心跳”的时间内完成；◼规划与其他操作单元的数据共享和数据锁定协议。客户机/服务器视图代码视图◼展示了如何将功能映射到代码单元上。◼应用程序被分

解为Ada程序包，这些程序包中只有类型定义。打包（packaging）是一种设计活动，其目的是包含抽象和信息隐藏。分层视图容错视图◼高可用性决定了系统出现故障时不能进行冷启动。直接（或比较快地）切换到备用组件是必须的。◼容错层次捕获应用程序间的交互的错

误并从中恢复。容错视图Summary图书管理系统◼图书馆管理系统中的书籍管理功能：◼书籍信息类◼书目类◼新增书籍界面类◼删除书籍界面类◼书籍管理类类顺序图:administrator:ActionForm:Sys

tem1:login2:login3:viladate4:viladateresult5:viladateresult6:delete7:delete8:delete9:deleteresult10:deleteresult协作图:administrato

r:ActionForm:System1:login2:login3:viladate4:viladateresult5:viladateresult6:delete7:delete8:delete9:deleteresult10:deleteresult软件体系结构上机案例◼学校每一

个学生都有两类书籍◼第一类是学生常用书籍，另外一类是一些贵重的书籍。◼对于常用，学生在借阅时需要进行登记（Register），自行保管，但在损坏时需要进行注销（Cancellation）和赔偿。◼而对于贵重书籍必须通过对外书籍管理系统进行统一管理。在使用时

需要办理租借（Lend）手续。需要注意的是，对于一般学生，只能借与自己专业相关的书籍（也就是本部门内的书籍），而对于研究生，则可以借所有类型的书籍。◼由于书籍分布在不同的地理位置。开发一套书籍仓库管理系统（BookWarehouseSystem,BWS）。

◼BWS主要分为两个部分◼第一部分是学生与书籍信息管理系统（StudentandBookManagementSystem,SBMS），详细记录书籍的借、还状态，学生可以通过本地学校局域网（Intranet）查询自己书籍的借还情况，并发出对贵

重书籍的请求。对于本地没有的特殊书籍，员工可以使用SBMS通过互联网（Internet）在全国图书仓库中查找特定书籍，并发出借用该书籍的请求。◼第二部分是一个书库的实时管理系统（BookWarehouseManagementSyst

em,BWMS），位于不同位置的的书库，在提取具体书籍时，用户需要到具体的书库进行书籍的提取。◼BWMS的具体要求如下。◼书库的实时管理系统中存在多个书籍抓取机器人，每个机器人都可从书柜上获取书籍并将其放在传送带上，传送带装置根据重

量传感器得知是否有书籍在传送带上，并将书籍传送到出口处。用户在的出口处向书籍管理员提交书籍租借请求，由管理员将该请求输入书库控制电脑，电脑控制书库中的机器人抓取相应的工具并将其放到传送带上，一旦机器人出现故障，将通知控制电脑以便及时进行维修。带开发的软件系统需要能够将分布

在控制电脑，机器人以及传送带上。（不考虑书籍归还系统）◼1）书库管理系统（BookWarehouseSystem,BWS）◼2）学生与书籍信息管理系统（StudentandBookManagementSyst

em,SBMS）◼3）书库的实时管理系统（BookWarehouseManagementSystem,BWMS）◼类图、顺序图、协作图、状态图、活动图、构件图◼体系结构风格说明