系统架构=业务架构+软件架构-ppt课件.ppt
- 【下载声明】
1. 本站全部试题类文档,若标题没写含答案,则无答案;标题注明含答案的文档,主观题也可能无答案。请谨慎下单,一旦售出,不予退换。
2. 本站全部PPT文档均不含视频和音频,PPT中出现的音频或视频标识(或文字)仅表示流程,实际无音频或视频文件。请谨慎下单,一旦售出,不予退换。
3. 本页资料《系统架构=业务架构+软件架构-ppt课件.ppt》由用户(三亚风情)主动上传,其收益全归该用户。163文库仅提供信息存储空间,仅对该用户上传内容的表现方式做保护处理,对上传内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(点击联系客服),我们立即给予删除!
4. 请根据预览情况,自愿下载本文。本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
5. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007及以上版本和PDF阅读器,压缩文件请下载最新的WinRAR软件解压。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 系统 架构 业务 软件 ppt 课件
- 资源描述:
-
1、第8章 系统架构设计v对于软件系统来说,描述系统架构一般涉及到两个方面的内容:业务架构和软件架构。这两方面内容分别针对于人们对业务领域的理解和对系统领域的理解。这两者是需要和谐统一的,前者从业务需求的角度出发,理清物理结构图和逻辑结构图,划分出每个子模块。确定为什么要这么划分,各个子模块之间如何交互,每个子模块具有哪些接口;后者从解决技术上讨论,着重讨论采用什么样的技术,如何分层,采用哪些好的技术特性,采用这些技术特性会为我们的工作带来哪些好处,为什么要这么做等。第1页第8章 系统架构设计v8.1 业务架构v8.2 业务架构分析v8.3 软件架构v8.4 软件架构设计v8.5 软件架构与框架v
2、8.6 软件架构的“41”视图模型v8.7 组件图v8.8 部署图第2页8.1 业务架构 v1. 问题引入问题引入系统架构一般涉及到两个方面的内容,其一是业务架构,其二是软件架构。人们常常会听到软件架构这个词,对软件架构的概念也有一些了解,但是,也许还有人对业务架构这个词比较陌生,那么,究竟什么是业务架构呢? 第3页8.1 业务架构v2. 解答问题解答问题业务架构描述了业务领域主要的业务模块及其组织结构。业务架构在先启阶段建立,在精化阶段得以改进(关于先启阶段、精化阶段等内容请读者参见第3章的RUP统一过程的相关内容)。业务架构的目的是为业务领域建立一个维护和扩展的结构,描述业务的构成。业务架
3、构对我们理解客户业务,尤其是对软件开发行业确定解决方案起着非常重要的作用。 第4页8.1 业务架构v3. 分析问题分析问题 软件开发一直在追求构件化,就像建房子一样来构建系统,用一块一块砌成不同形状的砖头来搭建自己想要的房子。在很多人看来,构件化开发是技术问题。即随着技术的发展,各种先进的架构和技术框架能够越来越多地解决复杂的现实问题,总有一天,我们能够利用一个极其灵活和强大的技术架构,将现实中的业务像搭房子一样构建出整个系统。但是,技术架构仅仅提供了您搭建房子的手段和方法,从可行性上给予您支持,您是否想过您砌成大大小小不同形状的砖头是什么呢?它们从何而来呢? 第5页8.1 业务架构可见,喜欢
4、和迷信技术的我们又忘了一个基本原则:技术服务于业务。尽管我们知道怎么样搭建房子,而手中却没有可用的砖头,怎么能建好房子呢?正所谓巧妇难为无米之炊啊。软件、技术通通是服务于业务的,技术只是保证做好系统的手段,一个好的软件其根本还在于业务的理解上。 第6页8.1 业务架构SAP是业界著名的ERP软件产品,它之所以能够做到通用,即使在不同行业间实施也只需很小的开发工作量,绝大部分需求都是通过配置来完成的。不是因为SAP采用了多么先进的技术架构,而是因为SAP把业务做到了极致,它已经砌好了那些可以搭建不同业务平台的各式各样的砖块。再复杂和迥异的需求,都可以用这些砖块搭建出来。这些砖块,就是业务架构。
5、第7页8.1 业务架构在项目开发过程中,当我们获得了一份需求时,如果不建立业务架构,那么这份需求对我们来说就是一盘沙子,每次我们都要从头把沙子做成砖块,一点点辛苦地开发程序。而建立业务架构的工作,就是要把沙子变成各式各样的砖块、部件,从部件做起而不是从沙子做起,像拼图一样,拼出我们的世界来。 第8页8.1 业务架构但这项工作是非常困难的,需要非常精深的行业知识。并且不是一朝一夕就可行的,必须通过几个甚至几十个项目的累积,才有可能总结出可用的拼图。在开发项目时,仅将业务架构作为项目中的一项工作,它可能不会对你当前的项目带来什么好处,但是随着每一个项目的积累,不断地修正和丰富业务架构,手中可用的砖
6、块就会越来越多,越来越丰富。总有一天,你可以用拼图来完成项目中大部分的业务需求,也就是行业解决方案的形成。 第9页8.2 业务架构分析v分析工作往往被模糊化,经常的情况是需求弄清楚以后直接进入设计阶段,例如详细的表结构、类方法、属性、页面原型等,然后就进入编码阶段了。那么分析与设计之间究竟存在什么样的差别呢?从工作任务上来说,分析做的是需求的计算机概念化;设计做的是计算机概念实例化。从抽象层次上来说,分析高于实现语言、实现方式;而设计则基于特定的语言和实现方式。因此分析的抽象层次高于设计的抽象层次。从角色上来说,分析由系统分析师承担的,而设计则由设计师来承担。从产出物上来说,分析的典型成果是分
7、析模型和组件模型,设计的成果是设计类、程序包等。 第10页8.2 业务架构分析v系统分析是在不考虑具体实现语言和实现方式的情况下,将需求在软件架构和框架下进行的计算机模拟。系统分析的目的是确定系统应当做成什么样的设想,而系统设计的目的是将这些设想转化为可实施的步骤。如果类比于房屋装修,分析相当于绘制设计图,而设计则相当于绘制施工图。分析决定哪个地方用哪个物品来装饰,设计决定如何装饰,用什么工具来装饰。 第11页8.2 业务架构分析v事实上,经过分析之后,已经决定了系统要做成什么样子,已经完成了从需求到系统的转换过程。至于接下来是用JAVA还是C#,是用J2EE还是.NET,是用两层结构还是用三
8、层结构,是用工厂模式还是用适配器模式就已经不是问题的重点了。不论采取什么样的实现方式,得到的结果无非是程序运行效率的高低、扩展性、可维护性的差别,无论如何都不会影响系统实现需求这一最基本的要求。 第12页8.2 业务架构分析v8.2.1 客户服务系统业务架构分析v8.2.2 客户服务系统子模块划分第13页8.2.1 客户服务系统业务架构分析 v1. 问题引入问题引入上面我们已经了解了分析与设计的区别,接下来将讨论客户服务系统的业务架构分析与实现。 第14页8.2.1 客户服务系统业务架构分析v2. 解答问题解答问题客户服务系统的业务架构如图8-1所示。第15页8.2.1 客户服务系统业务架构分
9、析电话咨询客户客服人员维护人员部门领导管理员投诉处理维护处理回访处理信息查询系统管理图8-1 客户服务系统业务架构 第16页8.2.1 客户服务系统业务架构分析v3. 分析问题分析问题对客户服务系统业务架构的分析立足于对需求足够理解的基础之上,我们知道软件开发中最重要的就是抽象,也就是采用OO(面向对象)的思想,这个思想应贯穿于软件开发过程的始终。需求作为分析过程的输入,需求分析后,产生用例模型和领域模型。用例模型和领域模型是业务架构的基础。如果只有用例模型和领域模型而没有业务架构,我们将“只见树木不见森林”。因为不论是用例模型还是领域模型,它们都只是业务领域的一部分。如果说用例模型代表了一个
10、软件项目对需求的定义和理解,那么架构就代表了一个软件项目对系统的定义和理解。架构将系统规划为一些独立的逻辑组件,各负其责,这些组件通过标准的通信接口传递信息。一个架构就是一个系统的骨架。 第17页8.2.1 客户服务系统业务架构分析v通过整理客户服务系统的需求,我们摘录出系统的核心业务如下:(1) 公司客户通过电话完成对软件产品或项目提出使用中的BUG或疑难问题以及投诉建议等内容。(2) 客户服务人员代理公司客户将咨询内容录入到客户服务系统中,以供备案查询。(3) 部门领导负责处理相关客户的投诉建议及故障申报,并视具体情况安排维护人员上门维护及安排客户服务人员进行回访。(4) 维护人员通过查询
11、任务安排,接受相关派工任务,并填写维护报告。(5) 客户服务人员通过查询任务安排,接受相关回访任务,并填写相关回访报告。(6) 系统管理员对系统基础资料进行维护管理。(7) 部门领导可以查询客户服务人员及维护人员的工作完成情况。v由此分析出客户服务系统的核心业务架构,用业务活动图表示如图8-2所示。 第18页8.2.1 客户服务系统业务架构分析图8-2 客户服务核心业务活动图 第19页8.2.1 客户服务系统业务架构分析v业务架构与核心模型的关系可用图8-3来表示。用例模型、领域模型所描述的业务过程,通过抽象可得到业务架构。反过来,业务架构对用例模型和领域模型则有着重要的指导作用。尤其在业务架
12、构改进的时候,某些用例可能需要重组,领域模型也可能重构。 第20页8.2.1 客户服务系统业务架构分析图8-3 业务架构与核心模型的关系 第21页8.2.1 客户服务系统业务架构分析v从图8-3可以看出,实际上建立业务架构的活动是一个反复迭代的过程,且非常类似于面向过程的结构化设计,不同的是,在结构化设计方法中,得到的结果是子系统、模块;而在面向对象的设计方法中,得到的结果则是业务组件。 第22页8.2.2 客户服务系统子模块划分客户服务系统子模块划分v1. 问题引入问题引入了解客户服务系统的业务架构图之后,接下来我们应该做的就是对客户服务系统划分模块。 第23页8.2.2 客户服务系统子模块
13、划分客户服务系统子模块划分v2. 解答问题解答问题客户服务系统的子模块如图8-4所示。第24页8.2.2 客户服务系统子模块划分客户服务系统子模块划分客服系统系统管理模块客服业务处理模块信息查询统计模块图8-4 客户服务系统子模块 第25页8.2.2 客户服务系统子模块划分客户服务系统子模块划分v进一步划分模块,系统管理模块、客户服务业务处理模块、信息查询统计模块分别划分为如图8-5、图8-6、图8-7所示的子模块。 第26页8.2.2 客户服务系统子模块划分客户服务系统子模块划分系统管理模块客户资料管理系统用户管理产品及项目管理经验库管理系统维护管理图8-5 系统管理模块 第27页8.2.2
14、 客户服务系统子模块划分客户服务系统子模块划分客服业务处理模块客户咨询管理咨询投诉报障派工管理维护安排回访安排图8-6 客户服务业务处理模块 第28页8.2.2 客户服务系统子模块划分客户服务系统子模块划分信息查询统计模块基础资料查询统计客户咨询查询统计派工单完成情况查询统计报表查询图8-7 信息查询统计模块 第29页8.2.2 客户服务系统子模块划分客户服务系统子模块划分v3. 分析问题分析问题(1) 客户服务系统子模块在得到业务架构的基础上,我们对客户服务系统的业务进行细分为以下三个子模块:v 系统管理模块。包括客户基础资料录入修改,客户服务系统用户信息的添加、删除和修改,软件产品的基础资
15、料维护,已上线项目的基础资料维护,FAQ经验库的数据维护以及客户服务系统本身的维护管理等。v 客户服务业务处理模块。包括客户咨询服务处理、故障申报处理、投诉处理,部门领导派工处理,客户服务人员回访处理,维护人员上门处理等。v 信息查询统计模块。包括基础资料查询统计,客户咨询的查询与统计,派工单完成情况,回访报告,维护报告查询统计以及相关报表的查询等。 第30页8.2.2 客户服务系统子模块划分客户服务系统子模块划分v(2) 各子模块的功能 系统管理模块v客户资料管理客户资料是客户服务系统的根源,只有健全的客户资料体系才能够保证客户服务有序地开展。主要包括录入客户资料、修改客户资料、删除客户资料
16、和查询客户资料等功能。v系统用户管理包括本系统的所有使用者的信息资料管理及查询。v产品管理包括公司所有发布的软件产品信息的管理及查询。v项目管理包括公司所承担的各种软件研发项目信息的管理及查询。v经验库管理包括经验信息的管理及查询。 第31页8.2.2 客户服务系统子模块划分客户服务系统子模块划分 客户服务业务处理模块。v客户咨询管理包括客户咨询信息的管理及查询。客户咨询服务活动如图8-8所示。 第32页 图8-8 客户咨询服务活动图 第33页8.2.2 客户服务系统子模块划分客户服务系统子模块划分v派工管理当有客户投诉及报障时,部门领导会立即对投诉及报障的客户作出快速反应,及时安排派工任务。
17、对投诉的客户安排客户服务人员及时回访处理;对报障的客户安排维护人员进行上门维护处理。派工活动图如图8-9所示。 第34页 图8-9 部门领导派工活动图 第35页8.2.2 客户服务系统子模块划分客户服务系统子模块划分 信息查询统计模块v包括查询统计基础资料、客户咨询信息、派工单完成情况等信息,并可打印报表。 第36页8.3 软件架构v1. 问题引入问题引入经过业务架构的分析与建模,我们得到了许多业务构件,要将这些业务构件搭建起来需要了解软件架构的知识。那么什么是软件架构呢? 第37页8.3 软件架构v2. 解答问题解答问题软件架构是一种思想,一个系统蓝图,是对软件结构组成的规划和职责设定。一个
18、软件里有处理数据存储的、处理业务逻辑的、处理页面交互的、处理安全的等许多可逻辑划分出来的部分。传统的软件并不区分这些,将它们全部混合在一段程序里。软件架构的意义就是要将这些可逻辑划分的部分独立出来,用约定的接口和协议将它们有机地结合在一起,形成职责清晰、结构明朗的软件结构。 第38页8.3 软件架构v3. 分析问题分析问题一个典型的软件架构包括两个视角:广度视角和深度视角。这两个视角构成对软件架构的“立体”描述。广度视角即是我们常说的软件层次结构,它关注软件的分层,规定每一层的职责以及层与层之间的通讯标准。一般使用包元素来描述。图8-10展示了一个典型的多层架构的层次模型。第39页8.3 软件
19、架构图8-10 软件层次的广度视角架构图 第40页8.3 软件架构另一方面,软件架构还需要描述深度视角。所谓深度视角,是指广度视角中每一层的详细说明,它关注每一层以及每个部分的具体实现架构。例如可以针对业务实体层进行架构描述,也可以针对XMLBean进行架构描述。图8-11展示了业务实体层的深度视角视图。 第41页8.3 软件架构图8-11 软件层次深度视角架构图 第42页8.3 软件架构广度视角和深度视角将软件架构立体化了。层次构成了广度视角维度,而每一个层次的包、类的结构构成了深度视角维度。第43页8.4 软件架构设计v1. 问题引入问题引入软件架构设计就是要将我们在业务架构中设计出来的业
20、务构件有机地结合在一起协调工作。那么客户服务系统的软件架构是怎样的呢? 第44页8.4 软件架构设计v2. 解答问题解答问题客户服务系统软件架构图如图8-12所示。第45页DBWebServicesDaoDB ControlJDBCWeb层用Struts框架,负责展现业务数据和人机交互,包括FormBean(ActionForm)和Action负责处自Web的Request,负责业务逻辑处理。接收来自Web的Request,将业务逻辑处理转化成针对Value Object的增、删、改、查,然后将处理完成的VO由Web展示给用户Value ObjectValue Object是由Hibernat
21、e PO复合而成的一个POJO对象。针对特定的业务需求而设计。一个VO由多个PO组成,并可通过VO的getter和setter方法访问实际PO值。VO是dao,services和web层之间的标准传输格式负责业务数据逻辑处理。将Value Object分解成Hibernate PO交由DB Control处理,或将PO组合成Value Object交由Services处理。HibernateHibernate是符合Hibernate框架规范的POJO,一个PO对应一张数据表。PO在DB Control层生成,在Dao层组合成VO图8-12 客户服务系统软件架构图 第46页8.4 软件架构设计v
22、3. 分析问题分析问题根据需求,客户服务系统要求是B/S架构的,即浏览器/服务器架构。该架构有许多优点:客户端无需安装任何软件,只要有浏览器就可以使用系统,方便客户服务人员能即时处理客户问题。当业务架构确定后,至于是选用.NET来实现还是选用J2EE来实现并不重要,主要依据开发团队的技术素质而定,以期达到最小项目风险和减少开发成本的目的。本节选用J2EE来描述客户服务系统的软件架构分层模型,采用了MVC架构体系,结合当前使用最成熟的Struts + Spring + Hibernate框架,如图8-13所示。第47页8.4 软件架构设计 表示层 Struts-MVC Action, Actio
23、nForm, JSP, Struts-config, XML 等 业务层 Spring Transactions Hibernate Session Management Business Service Classes 永久层 Hibernate DataSource /connection pool Query Language 等 提交服务 Dao 类 领域模型业务对象 图8-13 Struts+Spring+Hibernate框架图 第48页8.4 软件架构设计Struts + Spring + Hiberante框架的WEB应用常常被扩展成4个各负其责的层次:表示层(Presenta
24、tion)、业务层(Business)、持久层(Persistence)、领域模型层(Domain Model)。前三层分别对应于Struts、Spring、Hibernate,而领域模型层则是由那些现实世界中的业务对象组成,如客户、咨询、回访、投诉等等,它们是在上面三个层之间传递的对象。每层职责明确,彼此独立,通过专门编写的接口传递消息。 第49页8.4 软件架构设计客户服务系统分为四个层次,其中WEB层采用Struts框架,Service和Dao采用Spring框架封装客户服务业务逻辑处理,DB Control层采用Hibernate框架。VO(Value Object,值对象)和PO(P
展开阅读全文