第一章
完整的软件产品,包括在不同规模和体系结构的计算机上运行的程序,程序运行过程中产生的各种结果,各种以硬拷贝或电子媒介的形式存在的描述信息。
软件过程是工作产品构建时所执行的一系列活动、动作、任务的集合。
程序构件(模块)的结构或组织,这些构件交互的形式以及这些构件所用数据的结构。
一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。
在不改变软件现有功能的基础上,通过调整程序代码改善软件的质量、性能,使程序的设计模式和架构更趋合理,提高软件的扩展性、维护性。
软件系统的结构,包含软件元素、软件元素外部可见的属性,以及这些软件元素之间的关系。
不能测量,就不能控制
人件
渐进主义
迭代方法
修复代价增加
折中是非线性的
复用
风险管理
死亡之旅
不需要重新发明轮子
设计应使用可识别的体系结构风格、模式创建,由具备良好设计特征的构件组成,最后,以进化的方式实现,从而便于实现和测试。
设计应模块化,软件应该按照逻辑划分为元素或子系统。
设计应包含数据、体系结构、接口、构件的明确表示。
设计应导出数据结构,这些数据结构适于要实现的类。
设计应导出显示独立功能特征的构件。
设计应导出接口,这些接口降低了构件之间、以及与外部环境连接的复杂性。
设计的导出,应根据软件需求分析过程中获取的信息,采用可重复使用的方法进行。
设计应使用能有效传达其意义的表示法来表达。
软件模型是指软件的一种抽象,目前,一般通过非数学模型来描述。
组件,能完成特定功能并能独立部署的软件合成单元。一个组件一般具有一个或多个接口,每个接口的功能由一个或多个方法实现。接口的具体功能,由组建对象实现。
通过定义独立于具体技术、可以扩展的通用描述手段,来描述服务和实现服务交互,而将服务实现的具体技术细节隐藏在内部,从而实现服务的无缝集成。
语义模糊:从根本上说,语义模糊是由于自然语言的二义性造成的。
由语义模糊引起的沟通障碍:非形式化描述在结构描述上存在着语义模糊的问题,必然导致一定的沟通障碍。
无法实现系统验证:因为无法发现设计中的矛盾,并且无法保证软件产品的质量,以至于系统最终会遭遇致命的错误。
不适于描述体系结构行为:事实上,体系结构行为描述不仅仅是声明系统模块的功能和不同模块之间的交互,也是系统验证的重要依据。虽然一些非形式化描述可以描述系统的内部行为,但是仍有如下缺陷:
语义模糊妨碍了系统行为描述的准确性
行为无法通过计算来预测。
非形式化描述不能够表述运行时的动态行为。
形式化描述可以用于系统描述,而且可以在不同层次上进行描述。
形式化描述在体系结构行为描述上更胜一筹。
形式化描述使得系统验证变得可行。
被称为参与者的外部用户所能观察到的系统功能的模型图。多用于静态建模阶段。
显示对象之间交互的图,这些对象是按时间顺序排列的。
经过50多年的软件开发实践,今天,很少特开发的软件系统同以前的系统没有任何相似之处,识别相似系统的通用结构模式,有助于理解系统之间的高层联系。使得新系统可以作为以前系统的变种来构建。
合适的体系结构是软件系统成功的关健,而不合适的体系体构往往导致灾难性的后果。
对软件体系结构的准确理解,可以使开发人员在不同的设计方案中做出理性的选择。
体系结构对于分析和描述复杂系统的高层属性是十分必要的。
各种体系结构风格的提炼、描述和普遍采用,可以丰富设计人员的“词汇”,便于在系统设计中互相交流。
目前,相当大的维护工作量花费在程序理解方面,如果在软件开发文档中清整地记录了系统的体系结构,不仅可以显著地节省软件理解的工作量,而且便于在软件维护全过程中保持系统的总体结构和特性不变。
软件体系结构的设计方法,指一般首先是设计软件体系结构,获得满足系统功能性需求,并且符合一定非功能性需求约束的软件体系结构模型.(然后再逐步精化进行更加详细的设计一直到设计可以被实现的程度)
可信软件,指软件系统的运行行为及其结果总是符合人们的预期,且在受到干扰(包括操作错误、环境影响、外部攻击等)时,仍能提供连续的服务。
软件失效,泛指程序在运行中丧失了全部或部分功能、出现偏离预期的正常状态的事件。
改进软件结构提高模块独立性。
模块规摸应该适中。
深度、宽度、扇出、扇入都应适当
模块的作用域,应该在控制域之内。
力争降低模块接口的复杂程度。
设计单入口单出口的模块。
模块功能应该可以预测。
DSSA与软件体系结构风格,从不同角度出发研究问题的两种结果,前者从问题域出发,而后者从解决域出发。
DSSA只在某个特定领域中进行经验知识的提取、总结、组织,但可以同时使用多种软件体系结构风格。而一种软件体系结构风格所呈现的公共结构和设计方法可以扩展到多个应用领域。
DSSA的体系结构表示和工具,一般只适用于一个较小的范围,在其它领域中,是不适用并难以复用的。
对产品进行评审,而不是开发人员。
要有针对性,不要漫无目的。
进行有限的争辩.
闸明问题所在,但不要试图去解决问题。
要求事先准备,如果评审人没有准备好,则取消会议并重新安排时间。
为被评审的产品,开发一个检查表。
确定软件元素,是否遵循其规格说明或标准,记录任何不一致的地方。
列出发现的问题、给出的建议和解决该问题的负责人。
坚持记录并进行文档化.
构件放弃了对系统计算的控制。一个构件触发一个事件时,不能确定其它构件是否会响应它。而且即使知道事件注册了哪些构件的过程,也不能保证这些过程被调用的顺序。
数据交换的问题。有时数据可被一个事件传递,但在另一些情况下,基于事件的系统必须依靠一个共享的仓库进行交互。这些情况下,全局性能和资源管理便成了问题。
既然过程的语义必须依赖于被触发事件的上下文约束,关于正确生的推理,就存在问题。
应当如何界定层次间的划分是一个较为复杂的问题。
更改行为的重叠。
降低效率。
不必要的工作。
难以认可层的正确粒度。
结构清晰,易于理解。
易修改,可维护性强。
可移植性强,重用粒度大。
一种建模技术,能以图形的方式刻画数据流从输入到输出的变换过程。
为了满足软件专业化标准化的需求,而产生的对软件的使用界面进行美化优化规范化的设计分支。
用户时间
基准时间
基准出错率
任务出错率
学习能力
记忆能力
主观看法
努力做到一致性。
允许熟练用户使用快捷键。
价值的反馈
设计说明对话框以生成结束信息。
提供预防错误和简单的错误处理手段
允许轻松的反向操作。操作应尽可能地允许反向。
支持内部控制点。
较少短时记忆
平衡原则。注意屏幕各个方向的平衡,不要过分拥挤。
预期原则。屏幕上所有对象的处理应一致化,使对象的动作可预期。
经济原则。在提供足够的信息量的同时还要注意简明,清晰。
顺序原则。对象显示的顺序,应依需要排列。
规则化。画面应对称,显示命令、对话及提示行在一个应用系统的设计中,尽量统一规范。
创建故事
简化导航
使其响应
确保访问
形式追随功能
颜色主题
定义字体
最强优化图像
极简主义
排除错误
总结和积累了前人成功的设计经验,通过对这些经验的学习,使得人们在面对新的设计问题时,不同再重复所有的环节,而是尽量套用已有的模式实施,以提高编程的效率。
优化的设计经验。
较高的复用性。
丰富的表达能力。
降低耦合性。
单一职责原则
开闭原则
里氏替换原则
依赖倒置原则
接口隔离原则
迪米特原则
将软件的功能以服务的形式通过互联网来交付,可以被使用者(最终用户或者第三方客户端程序)直接使用的独立的基本单元。
为了解决在因特网环境下业务集成的需要,通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。
平台的无关性
通用的通信信道
企业的互操作性
功能复用
拓展业务
服务器的中立性
安全的通信
独立的功能实体.
SOA架构中非常强调,实体自我管理和恢复能力。常见的用来进行自我恢复的技术,比如事务处理(Transaction)、消息队列(Message Queue)、冗余部署(Redundant Deployment)、集群系统(Cluster)在SOA中,都起到至关重要的作用。
2.大数据量低频率访问
因特网的环境下,这些调用给系统的响应速度、稳定性带来的影响都可以忽略不计。这些因素,往往是决定整个系统是否能正常工作的一个关键决定因素。因此,SOA系统推荐采用大数据量的方式,一次性进行信息交换。
3.基于文本的消息传递
由于因特网中大量异构系统的存在。决定了SOA系统必须采用基于文本,而非二进制的消息传递方式。
简化了用Java语言编写的企业应用系统的开发、配置。
是一系列微软的概念和与程序接口,利用这个接口,客户端程序对象能够请求来自网络中另一台计算机上的服务器程序对象。
一个国际协会,开始的目的是为分布式面向对象系统建立标准,现在致力于建立对程序、系统、业务流程建模的标准,以及基于模型的标准。
是OMG最具影响力的规范集,保证了应用程序的互操作性以及对于硬件平台、操作系统、编程语言以及网络与通信协议的无关性。
EJB以构件的形式组织服务器:EJB构件,是直接用Java语言编写的服务器构件。Java语言编写的跨平台特性,使得EJB构件可以非常方便地移植到各种操作系统平台和EJB服务器上。
EJB构件实现,仅需考虑应用需求,其系统级服务诸如事务管理、安全性、构件生命周期与线程等,都是通过EJB服务器自动进行管理的。
EJB体系结构具有面向对象、分布式、跨平台、可扩充性、安全性以及便于开发等特点,同时,还是以协议为中心的,任何协议都可以被利用。
组件和复用
大多数分布式应用都不是凭空产生的,现存的硬件结构、软件、组件、工具需要集成起来,以便减少开发与扩展时间以及费用。位置独立性
DCOM使得组件的位置完全透明,无论是位于客户的同一进程中或是在地球的另一端。任何情况下,客户连接组件与调用组件方法的方式,都是一样的。语言无关性
因为DCOM具有语言独立性,应用系统开发人员可以选择他们最熟悉的语言和工具,来进行开发。连接管理
DCOM提供了一个对应用完全透明的分布式垃圾收集机制。可扩展性
DCOM提供了许多特性,来增强应用的可扩展性。对称的多进程处理
DCOM通过使用Windows NT对于对称性多进程处理的高级支持功能,就能轻易地将应用从一个单处理机,扩展到庞大的多处理机系统上去。
评估的效果,对评估师经验的依赖程度较高。
“重量级”的评估技术,成本较高。
没有考虑知识的积累和应用问题,造成资源浪费
缺乏实用的评估信息管理工具
场景的生成方式不同
风险承担者商业动机表述方式不同
软件体系结构的描述方式不同
在软件系统的生命周期内对软件进行维护和软件更新的行为和过程。
对既有对象系统进行调查,并将其重构为新形式代码的开发过程。
搜寻并实现业务过程中的根本性改变,以取得突破性成果。
软件的逆向工程是分析程序以便在比源代码更高的抽象层次上创建出程序的某种表示的过程
正向工程也称为革新或改造,这项活动,不仅从现有程序中恢复设计信息,而且使用该信息去改变或重构现有系统,以提高其整体质量。
将软部件从其当前环境移动到新的目标环境的过程,移植前后,软件的功能基本保持一致。
连续变化定律:不断变化的环境里,软件必须要发生变化。
复杂度增加定律:作为一个不断发展和变化的软件,结构将会变得更加复杂,必须引入外在的资源来保持和简化这个结构。
大规模软件发展定律:软件的发展变化,是一个自我调节的过程,系统属性对每个系统版本都应当是大致不变的
组织稳定定律:软件的整个生命周期里,发展变化速度大致是不变的,并与投入系统开发的资源无关
保持一致定律:在软件的整个生命周期中,每个版本增加的系统变化量,都是大致相当的
迭代性:在软件进化过程中,必须不断地对系统进行变更,许多活动要比在传统模式中具有更高的重复执行频率。
交错性:软件进化既具有连续性,又具有间断性,二者是交错进行的。
多层次性:软件进化是一项多层次的工作,是多方面因素共同作用的结果。
反馈性:用户需求和软件系统所处的工作环境,总是在不断发生该变,一旦环境发生变化,就必须作出反馈,启动软件进化过程。
并行性:为了提高软件进化的效率,必须对软件进化过程进行并行处理。
云计算把计算和数据分布在众多分布式计算机上,这使计算、存储获得了很强的可扩展能力,并方便了用户通过多种接入方式(例如,计算机、手机等)方便地接入网络获得应用和服务。
超大规模
虚拟化
高可靠性
通用性
高可扩展性
按需服务
极其廉价
将计算从桌面移向数据中心
服务配置和云效益
性能可扩展性
数据隐私保护
高质量的云服务
新标准和接口
体量大:随着互联网技术的发展,数据呈现出爆炸性增长。数据的存储单位从过去的GB到TB,甚至达到PB、EB。
种类繁多:数据种类既有结构化数据,又有各种半结构化及非结构化数据。
增长速度快:
准确性: