软件项目实训及课程设计指导——软件系统概要设计中的系统架构设计示例

软件项目实训及课程设计指导——软件系统设计中的系统架构设计示例

1、软件系统概要设计中所涉及的主要设计内容和工作过程

（1）在软件应用系统项目的系统概要设计工作中，首先是要完成软件系统的总体架构设计及系统的分层设计，然后再利用UML包视图体现出软件系统架构设计的最终结果。

由于J2EE技术规范为开发复杂的、分布式企业级的应用系统定义了一套体系结构和技术规范，它不仅提供了一套完整的基于标准化模块的功能服务组件，而且也提供了对企业应用系统的标准纵向分层设计方案。如下示图为在J2EE技术平台下的软件应用系统的典型分层设计方案，在该分层设计中的系统各个层之间只存在单向依赖关系，从而较好地实现了各个层的封装和彼此间的隔离。

此外，该分层设计方案还可以使得软件应用系统中的每一层都能够为其所对应的上一层提供功能服务而成为服务的提供者，同时也作为下层的客户端而获得所需要的其他层所提供的功能服务。如下示图为某客户关系管理系统（CRM系统）总体架构设计结果的分层包图示例：

（2）在软件应用系统项目的系统概要设计工作中，其次是完成软件应用系统中的各个组件的划分，然后再利用UML组件视图画出体现出软件应用系统中的各个功能模块的构成和相互间的关系；如下示图为某客户关系管理系统（CRM系统）的组件图的局部截图示例：

（3）然后再对各个组件模块进一步细化并设计出构成组件模块的各个相关程序类（这包括业务功能实现类和业务实体类等）以体现软件应用系统的基本组成单元；如下示图为某客户关系管理系统（CRM系统）的设计人员在系统组件设计的基础之上完成的系统程序类设计的局部截图示例：

（4）最后系统设计人员则根据前面的实体关系图（ER图）设计出软件应用系统的数据库表的逻辑结构，从而根据实体关系图（ER图）可以设计或者在某个平台工具中导出对应的某个数据库系统表结构的设计结果，最终获得针对某个数据库系统的表结构定义，从而获得软件应用系统依据某个物理数据库系统平台下的各个数据库表结构设计的结果。如下示图为某软件应用系统中用户信息数据库表结构定义的局部截图：

如下图所示的树形目录表示了软件应用系统项目的系统概要设计中所涉及的主要内容和所应该产生出的设计结果。当然在软件应用系统的概要设计工作中还需要制定出各种形式的规范——代码规范、接口规约、命名风格等。因为，这些规范是项目小组以后共同开发的基础，并且它能够使得整个软件系统的开发工作可以协调、稳定和有序地开展。

2、软件系统架构设计工作中应该要考虑的一些问题——首先是软件系统开发平台的合理选择

由于目前在企业通用应用系统的开发中主要存在有J2EE和https://www.360docs.net/doc/a24590354.html,两种不同形式的开发平台，软件应用系统的系统架构设计人员首先则是需要决定本软件应用系统项目到底应该是采用J2EE还是https://www.360docs.net/doc/a24590354.html,开发平台作为技术实现的平台。

尽管在表现形式上，J2EE是一组技术规范，而https://www.360docs.net/doc/a24590354.html,更像是一种产品。但它们的目的

其实都是为企业应用系统提供分布式的、高可靠性的解决方案和技术支持。“平台无关、技术实现中立、丰富的开源资源”是软件应用系统的设计人员在选择J2EE技术平台时的主要考虑因素。如下示图是百科中对J2EE技术平台的技术特性描述文字的局部截图：

本系列文章中所给出的示例项目——银行账户信息管理系统项目之所以采用J2EE技术平台进行开发实现，是因为J2EE平台能够更好地解决企业应用中的“信息共享”和“服务集成”两大技术问题以及具有如下的技术特性：

（1）系统的安全性高——J2EE提供了从平台到应用级的安全规范

（2）系统的稳定性和可用性好——J2EE是基于Java的健壮性和虚拟机实现的一致性基础上的

（3）系统的可扩展性和可伸缩性好——J2EE能够满足企业对应用系统逐步升级的需要和能够实现快速开发部署。

当然，J2EE技术平台的技术是非常成熟的——许多大牌厂商在技术方面都对其提供全力支持、并且有众多成熟的开源框架和技术平台对其提供良好的技术支持等这些方面的因素也是本项目要选择J2EE技术平台的其它方面的考虑因素。

3、软件系统架构设计工作中应该要考虑的一些问题——其次是合理地选择和采用C/S还是B/S软件体系架构

C/S（客户/服务器模式）和B/S（浏览器/服务器描述）软件体系架构是当今软件系统开发模式中的技术架构的两大主流技术。C/S是美国Borland公司最早研发的，而B/S是美国微软公司研发的。B/S软件体系结构有其特有的优点，但B/S软件体系结构在企业应用系统的开发中也反映出许多的不足之处。

传统的C/S体系结构并非一无是处，而现在主流的B/S体系结构也并非十全十美。因

此，C/S体系结构与B/S体系结构的应用系统还将在一定的时期内共存。而且有许多软件企业为了使得自己的应用系统能够更广泛地满足不同应用平台下的用户需求，往往会对同一个软件系统提供多个平台的版本，如C/S版、B/S版以及移动App版（包括平板电脑版等）。

因此，软件系统的设计人员需要找出影响软件系统架构选择的决定因素有哪些、并合理地进行权衡——软件系统的设计应该是理性地“思考”和“选择”的最终结果——“没有最好、只有最合适”。如下示图为蓝梦CRM管理系统应用B/S软件体系架构设计开发的数据查询显示结果的页面局部截图。

本系列文章中所给出的示例项目——银行账户信息管理系统项目之所以要采用B/S软件体系架构，主要是基于希望本应用系统的客户端程序能够达到“零维护”的效果——因为浏览器的客户端能达到这样的效果，不需要在系统版本升级时用户需要不断地更新系统。

4、软件系统架构设计工作中应该要考虑的一些问题——最后是合理地选择什么类型的应用框架

软件应用框架提供了一个概括的体系结构模板和共享的应用组件，软件应用系统的设计人员可以应用这个体系结构模板和共享的系统组件快速地构建出特定应用领域中的应用系统程序；软件应用框架其实也就是某种特定应用场景的半成品，目前在J2EE技术平台中提供有大量的框架平台和开源框架系统。

通过应用框架方式的系统开发，软件应用系统的设计人员能够实现在软件应用系统的分析、设计和程序模块类的程序代码的实现等方面得到多层次的系统重用，大大地降低了大量的重复性系统设计和程序模块开发实现的工作量，最终能够使得软件应用系统的开发实现与工业化中的大工业生产是一样的生产模式，从而大大地提高了软件应用系统的设计、开发和实现的总体效率。如下示图为Spring框架的官方网页面中对Spring应用框架的功能描述的局部截图：

目前在J2EE技术平台中具有非侵入性和独立于容器性的轻量级框架技术越来越受到开发人员的青睐。因为它不会强迫软件应用系统中的核心业务对象必须要遵循某个应用平台的特定接口规范——这将能够允许开发人员利用POJO（Plain Ordinary Java Objects，简单的Java对象）形式的Java程序类来实现软件应用系统中的业务逻辑功能。从而可以实现或者达到在容器外的开发和测试、并提高软件应用系统的总体开发效率。

因此，在软件应用系统中是否采用“开源框架”、以及采用什么类型的“开源框架”，软件应用系统的设计人员应该要根据本软件应用系统项目的具体应用要求进行合理的选择。

本系列文章中所给出的示例项目——在银行账户信息管理系统项目中选择“Struts2框架 + JavaBean组件技术”形式的体系架构以提供更好的表示层的技术支持。主要的技术选择的依据是本软件应用系统项目的业务功能处理比较简单，并且数据访问方面的功能实现也并不复杂，因此不需要采用Spring和Hibernate等开源框架，而是采用比较经典的Struts2 MVC开源框架以简化软件应用系统表示层的设计和开发实现。

5、画出体现软件应用系统项目最终的系统架构设计结果的分层UML包图

（1）UML中的包图

利用程序包可以组织和管理软件应用系统中的各个功能模块，从而使得整个软件应用系统的对象模型呈现出一种树形的层次结构——在UML的技术规范中把这种分组的机制称为包。

通过应用UML中的包图能够体现出软件应用系统中问题域的层次关系，这对于一个大型的软件系统来说，通过使用UML包的分组机制能够组织大量模型元素以便于项目开发小组中的各个成员对软件应用系统的理解和处理，并使之有很好的层次关系：因为通过应用UML包图可以把软件应用系统的模型元素组织成若干个组（包），并对这些包加以命名，从而可以将它们作为一个整体来处理，也可以分类处理；另外，通过应用UML包还可以形成一个高内聚、低耦合的程序类的集合。

（2）体现软件应用系统架构设计结果的UML分层包图

在软件应用系统的概要设计阶段，软件应用系统的设计人员可以用UML包图来表现软件应用系统的体系架构设计结果。因为通过体现软件应用系统分层的架构设计结果的包图，软件应用系统的设计人员可以图示化出本软件应用系统的分层设计方案。

本系列文章中所给出的示例项目——银行账户信息管理系统项目在纵向分层隔离方面采用四层次的系统架构设计，下图所示中的UML包图为体现本软件应用系统项目的系统架构设计结果的分层包图。

UML技术规范中的包与包之间所存在的依赖关系通常是指这两个包所包含的模型元素之间存在着一个或者多个依赖。如在一个包中使用另一个包中的模型元素，此时便可以认为它们之间存在着依赖关系。UML包的依赖关系的图形表示是采用虚箭头线，方向为从依赖包指向被依赖的包——如上图所示的依赖关系。

（3）软件应用系统架构设计的结果必须能够支持软件应用系统的扩展性要求软件应用系统最终能否达到可扩展性是作为评价优秀架构设计结果必须要考虑的一个设计目标，因为软件应用系统架构设计的结果必须能够支持软件应用系统的可扩展性，软件应用系统具有可扩展性的意义不仅在于使得软件应用系统本身具有良好的可扩展性，更关键的是由于分离了软件应用系统中的各个功能实现的关注点，使得软件应用系统的体系架构中的每一部分（或者功能组件）都可以独立地进行系统设计和程序开发实现。

但软件应用系统的扩展需求是来自于多个不同方面的——比如系统功能上的扩展，当然也还可能是非功能性方面的扩展考虑——比如：日志管理、安全控制和数据持久化技术实现的要求发生变化等。

因此，软件应用系统的设计人员必须要掌握如何分离软件应用系统中的这些关注点，才有可能保证所设计出的软件应用系统的系统架构设计的结果具有一定的可扩展性。