文档介绍：12 九月 2018
第1页
第8章系统架构设计
对于软件系统来说,描述系统架构一般涉及到两个方面的内容:业务架构和软件架构。这两方面内容分别针对于人们对业务领域的理解和对系统领域的理解。这两者是需要和谐统一的,前者从业务需求的角度出发,理清物理结构图和逻辑结构图,划分出每个子模块。确定为什么要这么划分,各个子模块之间如何交互,每个子模块具有哪些接口;后者从解决技术上讨论,着重讨论采用什么样的技术,如何分层,采用哪些好的技术特性,采用这些技术特性会为我们的工作带来哪些好处,为什么要这么做等。
12 九月 2018
第2页
第8章系统架构设计
业务架构
业务架构分析
软件架构
软件架构设计
软件架构与框架
软件架构的“4+1”视图模型
组件图
部署图
12 九月 2018
第3页
业务架构
1. 问题引入
系统架构一般涉及到两个方面的内容,其一是业务架构,其二是软件架构。人们常常会听到软件架构这个词,对软件架构的概念也有一些了解,但是,也许还有人对业务架构这个词比较陌生,那么,究竟什么是业务架构呢?
12 九月 2018
第4页
业务架构
2. 解答问题
业务架构描述了业务领域主要的业务模块及其组织结构。业务架构在先启阶段建立,在精化阶段得以改进(关于先启阶段、精化阶段等内容请读者参见第3章的RUP统一过程的相关内容)。业务架构的目的是为业务领域建立一个维护和扩展的结构,描述业务的构成。业务架构对我们理解客户业务,尤其是对软件开发行业确定解决方案起着非常重要的作用。
12 九月 2018
第5页
业务架构
3. 分析问题
软件开发一直在追求构件化,就像建房子一样来构建系统,用一块一块砌成不同形状的砖头来搭建自己想要的房子。在很多人看来,构件化开发是技术问题。即随着技术的发展,各种先进的架构和技术框架能够越来越多地解决复杂的现实问题,总有一天,我们能够利用一个极其灵活和强大的技术架构,将现实中的业务像搭房子一样构建出整个系统。但是,技术架构仅仅提供了您搭建房子的手段和方法,从可行性上给予您支持,您是否想过您砌成大大小小不同形状的砖头是什么呢?它们从何而来呢?
业务架构
可见,喜欢和迷信技术的我们又忘了一个基本原则:技术服务于业务。尽管我们知道怎么样搭建房子,而手中却没有可用的砖头,怎么能建好房子呢?正所谓巧妇难为无米之炊啊。软件、技术通通是服务于业务的,技术只是保证做好系统的手段,一个好的软件其根本还在于业务的理解上。
业务架构
SAP是业界著名的ERP软件产品,它之所以能够做到通用,即使在不同行业间实施也只需很小的开发工作量,绝大部分需求都是通过配置来完成的。不是因为SAP采用了多么先进的技术架构,而是因为SAP把业务做到了极致,它已经砌好了那些可以搭建不同业务平台的各式各样的砖块。再复杂和迥异的需求,都可以用这些砖块搭建出来。这些砖块,就是业务架构。
业务架构
在项目开发过程中,当我们获得了一份需求时,如果不建立业务架构,那么这份需求对我们来说就是一盘沙子,每次我们都要从头把沙子做成砖块,一点点辛苦地开发程序。而建立业务架构的工作,就是要把沙子变成各式各样的砖块、部件,从部件做起而不是从沙子做起,像拼图一样,拼出我们的世界来。
业务架构
但这项工作是非常困难的,需要非常精深的行业知识。并且不是一朝一夕就可行的,必须通过几个甚至几十个项目的累积,才有可能总结出可用的拼图。在开发项目时,仅将业务架构作为项目中的一项工作,它可能不会对你当前的项目带来什么好处,但是随着每一个项目的积累,不断地修正和丰富业务架构,手中可用的砖块就会越来越多,越来越丰富。总有一天,你可以用拼图来完成项目中大部分的业务需求,也就是行业解决方案的形成。
业务架构分析
分析工作往往被模糊化,经常的情况是需求弄清楚以后直接进入设计阶段,例如详细的表结构、类方法、属性、页面原型等,然后就进入编码阶段了。那么分析与设计之间究竟存在什么样的差别呢?
从工作任务上来说,分析做的是需求的计算机概念化;设计做的是计算机概念实例化。
从抽象层次上来说,分析高于实现语言、实现方式;而设计则基于特定的语言和实现方式。因此分析的抽象层次高于设计的抽象层次。
从角色上来说,分析由系统分析师承担的,而设计则由设计师来承担。
从产出物上来说,分析的典型成果是分析模型和组件模型,设计的成果是设计类、程序包等。