软件项目实训及课程设计指导——软件系统设计中的系统架构设计示例
1、软件系统概要设计相关的主要设计内容和工作过程)1)在软件应用系统项目的系统概要设计工作中，首先完成了软件系统的总体架构设计和系统的层次设计，然后利用UML包视图呈现软件系统架构设计的最终结果。
J2EE技术规范定义了一系列体系结构和技术规范，用于开发复杂的分布式企业级APP应用系统，因此不仅提供了基于标准化模块的完整功能服务组件，而且还为企业APP应用系统提供了标准下图是J2EE技术平台下软件应用系统的典型分层设计方案，该分层设计中系统各层之间只存在单向依赖关系，较好地实现了各层封装和相互隔离。
在该分层设计方案中，软件APP应用系统的每一层向相应的上层提供功能和服务，并且提供由作为下层中的客户端所需的另一层提供的功能和服务。 下图是一个客户关系管理系统(CRM系统)的总体体系结构设计结果的分层包图示例。
)2)在软件应用系统项目的系统概要设计工作中，首先完成软件应用系统中各组件的划分，然后利用UML组件视图表达软件应用系统中各功能模块的结构和相互关系。 下图是一个客户关系管理系统(CRM系统)的组件图的部分截图示例。
)3)然后，对于各组件模块，为了体现软件APP应用系统的基本构成要素，还包括构成组件模块的各相关程序类(其中包括业务功能实现类和业务实体类等) 下图显示了一个客户关系管理系统(CRM系统)的设计者根据系统组件的设计完成的系统程序类设计的部分屏幕截图示例。
)4)最后，系统设计人员根据前面的实体关系图(ER图)设计软件应用系统数据库表的逻辑结构，根据实体关系图(ER图)设计某平台工具对应的某数据库系统表结构的设计结果最终得到对某数据库系统的表结构定义，得到软件应用系统基于某物理数据库系统平台下各数据库系统的表结构设计的结果。 下图是在一个软件APP应用程序系统的用户信息数据库的表结构中定义的部分屏幕快照。
下图所示的树目录列出了软件APP应用系统工程系统概要设计中涉及的主要内容和应生成的设计结果。 当然，在软件应用系统的概要设计工作中，需要制定各种形式的规格——代码规格、接口规约、命名风格等。 因为这些规范是项目团队今后共同开发的基础，能够协调、稳定、有序地进行整个软件系统的开发工作。
2、软件系统设计工作中需要考虑的几个问题——首先是软件系统开发平台的合理选择
目前，企业通用APP应用系统的开发主要存在J2EE和VS.Net两种不同形式的开发平台，因此软件APP应用系统的系统架构设计者首先要考虑本软件APP应用的项目为J2EE和
在表达方面，J2EE是一系列技术规格，VS.Net就像产品一样。 但是，它们的目的是为企业的APP应用系统提供分散可靠的解决方案和技术支持。 “无论平台如何，技术实现中立、丰富的开源资源”是软件应用系统设计人员选择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）软件应用系统架构设计的结果必须能够支持软件应用系统的扩展性要求
软件应用系统最终能否达到可扩展性是作为评价优秀架构设计结果必须要考虑的一个设计目标，因为软件应用系统架构设计的结果必须能够支持软件应用系统的可扩展性，软件应用系统具有可扩展性的意义不仅在于使得软件应用系统本身具有良好的可扩展性，更关键的是由于分离了软件应用系统中的各个功能实现的关注点，使得软件应用系统的体系架构中的每一部分（或者功能组件）都可以独立地进行系统设计和程序开发实现。
但软件应用系统的扩展需求是来自于多个不同方面的——比如系统功能上的扩展，当然也还可能是非功能性方面的扩展考虑——比如：日志管理、安全控制和数据持久化技术实现的要求发生变化等。
因此，软件应用系统的设计人员必须要掌握如何分离软件应用系统中的这些关注点，才有可能保证所设计出的软件应用系统的系统架构设计的结果具有一定的可扩展性。