- 1. 系统概要设计中的架构设计教学目标
掌握系统的架构设计
掌握包图的建立
熟悉常用软件体系结构
掌握基于Java EE平台的架构技术
教学重点
包图的建立
基于Java EE平台的架构技术
教学难点
基于Java EE平台的架构技术
- 2. 导论概要设计中最重要的工作室系统的架构设计
架构设计
逻辑架构设计——包图
物理架构设计——部署图
- 3. 概要设计软件系统设计
系统设计:通过某种特定的平台,完成软件系统的整体功能(把软件需求转变为软件的具体方案),包括:概要设计和详细设计
具体工作内容:
需
求
分
析制定规范
体系结构设计
模块和组件类的设计
数据结构与算法设计
数据库的逻辑设计
其他如可靠性等方面的设计用户界面的设计
各个层中的组件类的设计
数据库的物理设计
测试计划的制定等概要设计详细设计
- 4. 概要设计软件系统设计
系统的概要设计:将软件系统的功能需求和非功能需求转化为数据结构和软件的系统结构,并合理地设计和规划出组成软件系统的物理元素:程序、数据库、过程、文件等内容
图书馆管理系统—架构
- 5. 概要设计软件系统设计
系统的详细设计
类图
活动图
组件图
- 6. 概要设计软件系统设计
为什么要进行软件系统的设计
主要原因:系统分析模型过于简单和粗糙
目的:指明一种易转化成软件系统功能代码的解决方案,是对系统分析工作的进一步细化和具体实现。也就是进一步细化分析阶段提取的各个类(包括其操作和属性),并且增加新的类以处理诸如系统中涉及的数据库系统、用户接口、与其他设备的通信、控制和驱动其他的设备等技术领域的问题
系统设计的基本要求
系统分析与系统设计之间应该是相互合作的
系统分析:面向问题的,是明确和了解问题的过程,重在理解和翻译,灵活性一般比较高
系统设计:面向解决方案的,是排除技术困难和解决问题的过程,重在精化和适应,受约束性和限制条件一般比较多。
进行系统设计时应注意的要点:
应该考虑能否使用重复的体系结构模式或者重用成熟的系统结构
体系结构从更高的层面上应该考虑的问题主要体现在“不变”因素上。
- 7. 概要设计软件系统设计
软件设计中的“3W”原则
Who——为谁而设计,应该明确软件系统的真正用户是谁
What——要解决用户在应用系统时的哪些问题,功能有哪些?性能又有哪些?
Why——为什么要解决这些问题?将这些问题解决后,能否为用户带来价值、降低开发方的成本等
围绕“用户”而非围绕“开发者”,开发者追求的设计目标:用户的需求、便于用户的使用同时又能使开发出的软件在应用新技术方面尽可能简单,相应的降低开发成本
常用的设计方法
面向过程的设计方法
面向对象的设计方法
- 8. 概要设计面向对象设计方法
特点:OOD(Object-Oriented Design)是“自下而上”,形成一种螺旋上升的软件开发方式
系统设计中的概要设计
概要设计(结构设计、总体设计)
涉及的主要内容:
制定本软件系统的开发规范:代码体系、模块间的接口和命名规则;设计文档的编制标准;规定与硬件、操作系统的接口规约和命名规则
体系结构设计(架构设计)
划分模块并进行组件类的设计
数据结构与算法设计
数据库的逻辑设计
其他方面
- 9. 概要设计系统设计中的概要设计
涉及系统设计的基本原则
先进性:在设计思想、系统构架、采用技术和选用平台上均要有一定的先进性、前瞻性和扩充性
实用性:简单、使用和人性化
可靠性
开放性
可维护性:分层设计、模块化并遵循面向接口编程
可伸缩性
可移植性
概要设计后的重要输出
概要设计说明书
数据库设计说明书
用户手册
制定初步的测试 计划,并对测试策略、方法、步骤提出明确要求
- 10. 软件架构设计软件架构及架构设计
在IT业,软件的系统架构是指通过某种特定的技术平台,完成软件系统整体功能的开发过程。
架构:软件系统结构通常被称为架构
必须考虑如技术方向、开发平台的选择、组件的构建、设计风格的确定、设计模式的具体应用、系统中各个模块职责的划分、协作、连接等问题
- 11. 软件架构及架构设计的重要性---Java软件开发中几种认识误区(1)Java及J2EE平台是目前比较主流的技术平台
如何更加地发挥Java及J2EE的技术优势?
(2)软件是有生命的并且它事关分层架构
一个有生命的软件首先必须有一个灵活可扩展的基础架构,其次才是完整的功能
过分依赖持久层技术---如应用存储过程和复杂SQL语句
持久层渗透并挤占业务层,腐蚀业务层软件的生命周期取决于系统的设计优良(3)对Hibernate等ORM技术没有正确地应用
没有利用延迟加载的特性
对象模型设计的不正确、特别是关系复杂
- 12. (4)Spring分层矛盾问题
Spring作为业务层框架,不支持业务层Session 功能。因此,对于会话跟踪只好通过HttpSession来实现。
从而使得业务层和Web表示层或者Servlet容器紧密藕合。一个良好的系统架构能够避免很多问题,但我们经常会出现下面的问题
(1)新颖的技术成为设计之本
(2)把软件当成自我表达的方式
(3)把软件设计成万能的
(4)过分强调功能,而不是使用的方便性 因此,如果系统设计的比较好,那么在后续开发中就能少走弯路,并且在后续的系统维护中也能够简单、轻松;但如果系统设计中就出现了问题,那么这个系统的开发必然是痛苦的,编程人员的不停抱怨、维护人员痛苦挣扎。
- 13. 软件架构一般概念
(1)什么是架构-----在IT,架构普遍指通过某种特定的平台,而达到完成整体软件的功能的设计过程。(2)Architecture
其英文的本意是来源于建筑行业的建筑艺术、建筑(风格)和结构。
就像高楼大厦的钢骨结构, 将无数个“Part” 组合成为和谐的“Whole”
- 14. 架构是一组有关如下要素的重要决策
(1)软件系统的组织
构成系统的结构化元素的选择
接口和它们相互协作的行为的选择
结构化元素和行为元素组合成粒度更大的子系统的方式的选择
(2)指导这一组织(元素及其接口、协作和组合方式)的架构风格的选择 在软件开发中,架构既可以是名词,也可以是动词----软件架构实际上是两个层面的事情。
(1)架构作为名词来理解
是指提供一个统一的共享的框架或者是Framework,这种架构事实上是系统的一个层,这里的架构是名词。
(2)架构作为动词来理解
是指设计构造系统或者是Archiecture,这里的架构更多的是动词(此时的架构一部分是调研工作,一部分是设计等工作)
- 15. 软件架构在软件系统开发中的位置
(1)一般的位置
架构设计往往发生在细节需求尚未完成的时候进行的。因此,随着项目的进行,需求还可能细化,可能变更。原先的架构肯定会有不足或错误的地方。
为了实现不断的改进,我们将在开发流程中引入迭代的概念。 (2)必要性------架构是软件设计中非常重要的一个环节
在软件开发的过程中,只要需求和架构确定之后,我们认为这个软件也就基本上可以定型了-----这就好比骨骼确定了,这个人的体形就不会有很大的变化一样!强调软件架构的最主要的目的是希望能够达到
(1)重用:人们希望系统能够重用以前的代码和设计,从而提高开发效率 这也将是我们在进行架构实践是所应该把握的原则
- 16. (2)扩展
人们希望在系统能够保持结构的稳定的前提下很容易地扩充功能和性能,希望能够“以静制动”----合理地应用成熟的框架。
(3)简洁
好的架构一定易于理解,易于学习,易于维护,人们希望能够通过一个简洁的架构来把握系统;
一个复杂的架构不论是测试还是维护都是困难的,因此我们希望架构能够在满足目的的情况下尽可能的简单明了软件架构的重要性体现在以下三方面
(1)软件架构是软件各相关方联系的载体
- 17. (2)软件架构代表了软件系统设计早期一系列重要决策
软件架构提供了如何满足软件系统的各项功能要求、并为各个部件的设计和其相互关系提供了必须遵守的约束
通过软件架构可以为设计工作和维护工作的组织、实施提供了依据。
软件架构可以提出系统应该实现的质量目标
根据这些质量目标,我们同时也能够预计出软件系统的某些质量属性。
软件架构为开发人员的技术培训提供了基础,同时也为软件产品维护阶段必要的变更提供分析根据。(3)一个成熟的软件架构可以为今后开发类似的产品提供参照。
- 18. 软件系统架构的主要工作内容
(1)架构调研----广义上,是对系统的重大设计决策有特别影响的需求进行分析
是指识别对系统存在或可能存在重大影响的功能性或非功能性需求(特别是非功能性需求)。
例如市场趋势、性能、成本、维护和系统演进等。
(2)架构设计----主要包括体系结构设计和各个层模块设计
是指对软件、硬件、网络、运营、政策等软件设计中的需求和要素进行决策。 在统一过程(RUP)中,架构调研和架构设计统称为架构分析。
- 19. (3)RUP 中所称的架构视图(Architecture View)
在RUP 中将“4+1 View”称为 Architecture View,即通过这样5种视图可以完整地展示系统的架构,同时不同的视图也是面对不同的人员的。
下面图示说明 架构由专门的设计师来设计,设计出的蓝图交由程序员来实现
- 20. (4)不同的视图所代表的含义
逻辑视图:当采用面向对象的设计方法时,逻辑视图即对象模型并关注功能。
实现(组件)视图
描述软件在开发环境下的静态组织;关注程序包,不仅包括要编写的源程序,还包括可以直接使用的第三方SDK和现成框架、类库,以及开发的系统将运行于其上的系统软件或中间件
进程视图:描述系统的并发和同步方面的设计。
部署视图:描述软件如何映射到硬件,反映系统在分布方面的设计。
(5)为什么对架构要采用多视图
架构要涵盖的内容和决策太多了,并且涉及不同方面的内容,不能采用某一种形式的图来描述,因此采用“分而治之”的办法从不同视角分别设计;
同时,由于也涉及不同方面的人员理解、交流和归档提供了方便。
- 21. 系统架构设计时所应考虑的问题
(1)何时开展架构----需求分析和建模完成后
当然,这需要项目经理以具体的经验判断来评估此时是否足以能够开始构建软件架构的工作。(2)架构设计工作不仅要依据静态的系统目标,也要考虑动态的开发过程
静态的系统目标
一般为:功能需求、非功能需求和变化的用例等
动态的开发过程
一般为:如人力资源的情况,进度要求的情况,开发环境的满足情况。
(3)针对不同需求进行架构设计
软件架构师必须全面把握各种各样的需求、权衡需求之间有可能的矛盾之处,分门别类地将不同需求一一满足。
- 22. (4)没有一个统一的“万能(通用)”的系统架构
因为,软件的系统架构设计是和千差万别的具体软件系统的要求、所应用的技术和开发平台等因素是密切相关的,因此在此无法给出一个通用的“系统架构设计”解决方案。
尽管存在上面的原因,但我们认为在“系统架构设计”中还是会有一些共性的东西,以及能够说明哪些因素是需要考虑的。当然,对于每个因素的设计策略和具体的解决方法还需要我们的软件架构设计师在具体开发实践中灵活把握-----不同因素之间有时是矛盾的,架构设计时需要根据具体情况进行平衡。
- 23. 架构设计的基本依据
(1)架构设计的主要依据首先是应用系统中的需求
(2)遵循J2EE平台中倡导的两个主要设计原则多层架构、松耦合。
如何验证系统架构设计的正确性
邀请专家和有相关经验人员对设计进行评审
快速原型法
代码验证
软件系统的架构师——总工程师
主要工作职责:保证在一个软件项目开发的过程中,能够将客户的各种需求转换为规范的开发计划及相关的文档;并制定这个项目的总体架构设计方案,同时还要指导整个开发团队完成这个设计方案的具体实现。
技术方向的决定、技术风险的承担,具体解决方案的提供者或者建议者
与项目经理紧密合作
最终保证软件项目能够按时、按质地顺利完成。
- 24. 软件系统的架构师——总工程师
主要任务
首先需明确的是“自己不做什么,而不是考虑做什么”
不应该只从纯技术的角度来考虑整个软件项目的实施
预见客户的技术走向,以便在早期决定技术研究的方向和积累技术经验
在架构设计的实践工作中,最好不要过分地追求新技术的应用
努力把自己培养和锻炼成为软件架构师
初始职业为程序员
程序员到高级程序员
程序员提升为设计师
设计是发展为架构师
软件架构师与系统分析师的区别(P91)
- 25. 软件架构设计的目标框架——具体化得架构
设计模式
目标:
能够最大化地重用——开源框架技术
使软件系统实现可扩展性——架构模式和代码设计模式
设计出“高内聚低耦合”的应用系统——分层设计
- 26. 软件架构设计的设计误区过分追求完美——“完美主义”的设计师
不负责任的架构师
- 27. 系统架构实践常用体系结构——C/S、B/S、RIA
C/S:客户/服务器,Borland公司研发
B/S:浏览器/服务器,微软公司研发
瘦客户端面临的一些新问题:最大缺点是无法利用客户计算机充足的内存和强大的计算能力,单靠服务器根本无法承载需要耗费大量内存的计算能力
表现能力方面
响应速度等性能方面
HTTP协议是一个无状态的协议
C/S和B/S将在一定时期内共存
企业应用系统:对外B/S,对内C/S
Web应用系统:前台B/S,后台C/S
Web
浏览器Web
服务器数据库
服务器应用
程序一应用
程序三应用
程序二Web
浏览器HTTP协议HTTP协议TCP/IP协议TCP/IP协议
- 28. 系统架构实践常用体系结构——C/S、B/S、RIA
RIA: (Rich Internet Application)富因特网应用程序
取B/S 和C/S之长
“富”:数据模型的丰富、全面提升GUI
实现形式:JavaScript+XMLHttpRequest(AJAX)、Smart Client+Web Service、Java Web Start、Flash Flex
面向框架的应用开发
面向对象编程和面向组件编程
框架
概括的体系结构模板
某种特定应用的半成品
应用平台
为什么程序框架并使用框架来开发系统
减少重复劳动
优点:
能够实现在分析、设计、类等多层次上的重用
使软件开发与工业化的大工业生产是相同的模式
同时还允许客户化地制定应用系统中的特性
- 29. 系统架构实践面向框架的应用开发
主流应用框架大多都包含下列问题的现成解决方案
持久性的支持(Persistence)
事务管理的提供(Transaction)
安全性认证和数据保护(Security)
日志记录(Logging)
面向框架的应用开发应该注意的问题
软件开发由应用系统开发转变为对应用系统的集成
以接口为中心,面向行为的设计和编程实现
开发团队的构建和人员构成问题
组件开发者
应用组件集成者
应用系统部署者
开发平台服务器供应商
应用系统开发工具供应商
系统管理员
- 30. 系统架构实践面向框架的应用开发
反思面向框架的应用开发给系统开发带来的问题
应用系统一般会产生一定的冗余
框架对应用系统总会有一定的限制
系统运行的效率
平台的锁定
人为地增加了学习的任务和负担
- 31. 系统架构实践应用轻量级框架技术架构应用系统
Java EE平台中的轻量级框架技术
轻量级Java技术
轻量级Java技术中的POJO(Plain Ordinary Objects)
应用轻量级框架技术的主要目的
降低开发过程中复杂性
可以在容器外开发实现,同时也缩短了应用程序的部署时间
有利于单元测试
Java EE平台中应用广泛的3个层次的轻量级框架技术
表示层:Struts2、JSF/Tapestry
业务组件层:Spring、Hivemind
持久层:Hibernate、JDO、iBATIS
轻量级框架在应用时应该注意的问题
轻量级框架不可能彻底代替高端应用服务器容器的品质
轻量级之所以“轻”是因为没有提供对J2EE EJB中的分布式远程功能的支持
轻量级框架的产生并非是对重量级框架的否定,在某种程度上甚至可以说二者是互补的
基于轻量级框架技术的系统架构设计示例(P109)
- 32. 系统架构实践网上商城项目的系统架构设计示例
P111
- 33. 小结介绍了软件系统逻辑架构的设计和实现
介绍常用了软件体系结构(架构模式)
B/S C/S RIA
介绍了轻量级应用框架
Java EE平台的轻量级框架技术
系统架构设计——包图