资料下载
×
实例分析基于构件技术的系统软件架构
消耗积分:1 |
格式:rar |
大小:0.6 MB |
2017-10-27
分享资料个
自从构件技术提出以来，如何有效地划分构件、进行最大化的软件复用成为研究的热点。构件化软件的最主要特征［1］在于目标系统由大量可复用构件组成，从系统化构件复用过程来看，传统软件开发方法中的详细设计被划分到了构件制作阶段，与基于构件开发目标系统属于相对独立的不同阶段。构件化软件的设计是传统软件开发方法中的总体设计或高层设计，要求设计阶段就应设计出满足需求的软件体系结构。
1 面向构件的软件架构
软件架构［2］是指某个软件或计算机系统的软件架构，即组成该系统的一个或多个结构，构成软件的各个部分，形成该构件的外部可见属性及相互间的关系。基于构件的软件架构，更加强调构件的概念，架构时考虑两个方面：（1）与软件基础设施有关，（2）与构件在基础设施上的操作有关。基于这两方面的考虑，通常在架构时考虑技术架构和应用架构两个方面。
1.1技术架构
技术架构［3］定义了技术环境和软件基础设施，是支持组织以实现运作（非功能）需求（尤其是组织的应用程序和信息体系结构）的硬件和软件基础设施的体系结构。它描述了所使用的技术的结构和内部关系，以及这些技术如何支持组织的运作需求。
技术架构包括技术环境和技术基础设施两个部分。技术环境解决不同软硬件平台之间的差异性问题。技术基础设施包括在应用中可以被标准化的部分。标准化使得通用代码从面向业务的构件中移出，放到一个独立的可复用的软件基础设施中。软件基础设施可以通过预先构建的构件框架的方式提供，它处理构件行为中已经标准化的方面。
1.2 应用架构
应用架构［3］包括了构件开发者和组装者面临的架构问题。是自服务的体系结构，用于支持和实现这样的业务需求，包括该业务与其他应用程序之间的接口。它描述了应用程序的结构以及该结构如何实现组织的功能需求。图1所示为面向构件的软件构架模型［4］。
2 典型系统架构分析
以一个门诊部信息管理系统为例，对基于构件技术的系统架构进行分析。
2.1 架构选型
根据需求分析过程中得到的用例模型，进行了如下选型过程［5］：
（1） 选择套装软件还是自行开发
先考虑了市场上套装软件的产品，希望借助成熟的产品加快实施进度，确保软件的质量和稳定性。但是通过考察，发现套装软件存在以下问题：
①从功能角度分析：市面上现有的系统虽然提供了丰富且强大的功能，但与本系统的需求交集只占了大约60%，此部分之外的需求需要花费很大的代价定制，而软件中约有50%的特性是本系统所不需要的。
②从实施周期角度分析：由于客户化的内容比较多，包括前期的需求映射和套装软件的模型调整，要完成实施，经过评估需要2年左右的时间，超出了用户的预期。
③从成本角度分析：套装软件相对比较昂贵，另外需要购买相应的咨询、实施服务，这样使得成本更大。
④从扩展性角度分析：套装软件集成了一套强大的模型，通过模型的配置，基本上可以满足业务上的变化，但是在条件不能满足的情况下，由于系统实现非常复杂，采用的技术手段包含了很多自由的标准，难于进行二次开发，不利于移植和维护。
基于以上的分析，选择了自行开发软件。
（2） 技术平台的选择
所谓“平台”就是能够独立运行并自主存在，为其所支撑的上层系统和应用提供运行所依赖的环境。
技术平台是一套完整的、严密的服务于研制应用的软件产品及相关文件。真正的技术平台应该是选择合适的技术体系（如J2EE、.NET等），技术架构（一组设计模式如MVC的集合），充分发挥技术体系及技术架构的优势，能够大大提高应用软件开发速度，指导并规范应用软件分析、设计、编码、测试、部署各阶段工作，提炼用户真正需求，提高代码正确性、可读性、可维护性、可扩展性、伸缩性等软件工具。优秀的技术平台还包括一套高效的底层通用的代码，甚至还包括代码生成器、代码安全漏洞检查工具等。
2.2 三层软件架构
在总结基于构件的软件架构方法和进行架构选型分析后，在本系统中引入三层结构的设计思想，采用构件化的开发方法，将系统业务逻辑封装在应用服务器上，客户端应用程序自动从应用服务器上下载和更新业务逻辑，达到“应用逻辑与程序代码分离，数据与应用分离，应用与流程分离”，最大化地支持业务的灵活开展。图2所示为系统软件架构。
系统采用三层体系结构设计。所谓三层体系结构［6］，即用户层、应用层和数据库服务器。用户层主要指用户界面，要求尽可能地简单，使最终用户不需要进行任何培训就能方便地访问信息；第二层是应用服务器，也就是常说的中间层，即组件层，所有的应用系统、应用逻辑、控制都在这一层，系统的复杂性也主要体现在应用层；最后的数据存储层中，数据库服务器存储大量的数据信息和数据逻辑，所有与数据有关的安全、完整性控制、数据的一致性、并发操作等都是在第三层完成。
1 面向构件的软件架构
软件架构［2］是指某个软件或计算机系统的软件架构，即组成该系统的一个或多个结构，构成软件的各个部分，形成该构件的外部可见属性及相互间的关系。基于构件的软件架构，更加强调构件的概念，架构时考虑两个方面：（1）与软件基础设施有关，（2）与构件在基础设施上的操作有关。基于这两方面的考虑，通常在架构时考虑技术架构和应用架构两个方面。
1.1技术架构
技术架构［3］定义了技术环境和软件基础设施，是支持组织以实现运作（非功能）需求（尤其是组织的应用程序和信息体系结构）的硬件和软件基础设施的体系结构。它描述了所使用的技术的结构和内部关系，以及这些技术如何支持组织的运作需求。
技术架构包括技术环境和技术基础设施两个部分。技术环境解决不同软硬件平台之间的差异性问题。技术基础设施包括在应用中可以被标准化的部分。标准化使得通用代码从面向业务的构件中移出，放到一个独立的可复用的软件基础设施中。软件基础设施可以通过预先构建的构件框架的方式提供，它处理构件行为中已经标准化的方面。
1.2 应用架构
应用架构［3］包括了构件开发者和组装者面临的架构问题。是自服务的体系结构，用于支持和实现这样的业务需求，包括该业务与其他应用程序之间的接口。它描述了应用程序的结构以及该结构如何实现组织的功能需求。图1所示为面向构件的软件构架模型［4］。
2 典型系统架构分析
以一个门诊部信息管理系统为例，对基于构件技术的系统架构进行分析。
2.1 架构选型
根据需求分析过程中得到的用例模型，进行了如下选型过程［5］：
（1） 选择套装软件还是自行开发
先考虑了市场上套装软件的产品，希望借助成熟的产品加快实施进度，确保软件的质量和稳定性。但是通过考察，发现套装软件存在以下问题：
①从功能角度分析：市面上现有的系统虽然提供了丰富且强大的功能，但与本系统的需求交集只占了大约60%，此部分之外的需求需要花费很大的代价定制，而软件中约有50%的特性是本系统所不需要的。
②从实施周期角度分析：由于客户化的内容比较多，包括前期的需求映射和套装软件的模型调整，要完成实施，经过评估需要2年左右的时间，超出了用户的预期。
③从成本角度分析：套装软件相对比较昂贵，另外需要购买相应的咨询、实施服务，这样使得成本更大。
④从扩展性角度分析：套装软件集成了一套强大的模型，通过模型的配置，基本上可以满足业务上的变化，但是在条件不能满足的情况下，由于系统实现非常复杂，采用的技术手段包含了很多自由的标准，难于进行二次开发，不利于移植和维护。
基于以上的分析，选择了自行开发软件。
（2） 技术平台的选择
所谓“平台”就是能够独立运行并自主存在，为其所支撑的上层系统和应用提供运行所依赖的环境。
技术平台是一套完整的、严密的服务于研制应用的软件产品及相关文件。真正的技术平台应该是选择合适的技术体系（如J2EE、.NET等），技术架构（一组设计模式如MVC的集合），充分发挥技术体系及技术架构的优势，能够大大提高应用软件开发速度，指导并规范应用软件分析、设计、编码、测试、部署各阶段工作，提炼用户真正需求，提高代码正确性、可读性、可维护性、可扩展性、伸缩性等软件工具。优秀的技术平台还包括一套高效的底层通用的代码，甚至还包括代码生成器、代码安全漏洞检查工具等。
2.2 三层软件架构
在总结基于构件的软件架构方法和进行架构选型分析后，在本系统中引入三层结构的设计思想，采用构件化的开发方法，将系统业务逻辑封装在应用服务器上，客户端应用程序自动从应用服务器上下载和更新业务逻辑，达到“应用逻辑与程序代码分离，数据与应用分离，应用与流程分离”，最大化地支持业务的灵活开展。图2所示为系统软件架构。
系统采用三层体系结构设计。所谓三层体系结构［6］，即用户层、应用层和数据库服务器。用户层主要指用户界面，要求尽可能地简单，使最终用户不需要进行任何培训就能方便地访问信息；第二层是应用服务器，也就是常说的中间层，即组件层，所有的应用系统、应用逻辑、控制都在这一层，系统的复杂性也主要体现在应用层；最后的数据存储层中，数据库服务器存储大量的数据信息和数据逻辑，所有与数据有关的安全、完整性控制、数据的一致性、并发操作等都是在第三层完成。
声明：本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人，不代表电子发烧友网立场。文章及其配图仅供工程师学习之用，如有内容侵权或者其他违规问题，请联系本站处理。 举报投诉
评论(0)
发评论
- 相关下载
- 相关文章
