构架模式UML与组件设计.ppt

《构架模式UML与组件设计.ppt》由会员分享，可在线阅读，更多相关《构架模式UML与组件设计.ppt（136页珍藏版）》请在三一办公上搜索。

1、1,构架模式、UML与组件设计,竞争的优势,2,议程,软件架构与模式UML:通用建模语言 组件设计过程,3,议程,软件架构与模式架构的定义优秀软件的标准模式UML:通用建模语言 组件设计过程,4,民用建筑中的受力,压缩,拉伸,负载的种类-固定的负载-变化的负载-动态负载防止失败-安全因素-冗余-均衡,任何时间你必须放弃原有经验,使用10倍的力量,再加以10倍的调研.对于大的项目尤为如此.,5,软件构架中的受力,Have an architecture that makes sense before you write 3.5 millionlines of code.,区别-没有运动的部分-可

2、以创建新材料-可以改变物理现象避免失败-将关键部分分散开来-语义上的一致性-职责分散,6,复杂性度量,更高的技术复杂性-内嵌的，实时的，分布的，容错的-定制的，空前的，结构重新设计-高性能,更低的技术复杂性-大多数是 4GL,或者是基于组件的-应用程序重新创建-交互式性能,更高的管理复杂性-大规模-契约的-多个资金保管者-“工程”,更低的管理复杂性-小规模-非正式的-单个资金保管者-“产品”,Walker Royce,Rational,7,构架的定义,软件构架是围绕着一系列关于软件系统组织的重要决定选择组成系统的结构单元和接口这些单元之间的协作行为这些单元之间的协作行为综合这些小的结构和动作单

3、元为较大的子系统管理整个组织的结构形式,8,构架的定义,软件构架同时包括用法功能性性能可恢复性可重新利用率综合性经济和技术的相互约束和权衡关系审美学的观点,9,以构架为中心,目的智能控制以可重复利用为基础以项目管理和减小危险性为基础表示方法4+1 视图模型步骤迭代的和增量的发展从可执行的构架中进行连续地提炼,10,构架的前后联系,选择在什么规章或契约之下组建软件是一个构架级的决定,但这绝不是一个完整的构架级决定,11,除去变化的层,12,分层设计的 MS Search 2.5,代码的组件化（模块化）是第一位的。相比2.0版本三个主要的搜索功能。而 Search 2.5 由于把应用程序分割为不同

4、模块，分别处理代码的执行和用户界面的表示，从而实现了代码与界面的分离。这是通过 XML 和 XSL 来实现的。,13,构架的定义,查询先被提交给解析器(Parser)进行词条分割和词表解析找到项目的显示术语(Display Term)被传给 Best Bets找到项目的首选术语(Preferred Term)和剩余项目被传给 Search Results使用 XSL 编译生成并转换为 XML 格式的结果文档HTML 被提交到用户 Web 浏览器,14,完成优秀的设计,通过如下方法达到：以用户为中心的方法与企业架构相一致构建时规划基于解决方案的设计迭代过程完全的MSF团队输入,15,优秀的设计,

5、有用的解决商业问题保证信息、服务和产品的交付可用的保证生产率直觉的无错的期望的性价比高的灵活的可扩展的可维护的,16,降低设计风险,MSF设计过程是一个有效的工具，用以降低那些因为不满足商业需求而产生的设计风险。,17,模式,模式是针对一个特定问题的解决方案模式是从一个领域的经验中所提炼出来的特定的知识所有具有良好结构的系统都有非常丰富的模式习惯用语设计模式构架的模式,18,设计模式,创造性的模式抽象factory原型构架的模式适配器桥代理动作的模式职责链协调者访客机制是构架的灵魂,19,模式与架构的来源,20,受关注的程度,发现,发明,实施,注意力,时间,21,讨论,一个典型的设计优秀的架构

6、吸取的教训得到的经验,22,议程,软件架构与模式UML:通用建模语言 OODA:面对对象的分析与设计UML介绍使用案例视图类图表交互图表与行为图表模块与组件组件设计,23,OODA:面对对象的分析与设计,类、对象以及元件 一般概念,24,类、对象以及元件,类：蓝图，对象的模版对象：类的实例元件：一个系统的物理执行单元包括一个或多个类，很强的依存关系物理的、可用二进制表示的应用程序可运行一个或以上的界面包含一个或以上的类别可替换性,25,类和对象,对象的状态有时间变化的趋势 类是对象的抽象,JaneLewis1/27/56,DonSmith7/9/63,DebbyBloom6/18/67,War

7、renJohnson8/28/52,26,OOAD的一般概念,抽象封装模块继承,27,OOAD的基本概念：抽象,管理复杂性 关注实际的特性 忽略详细说明 从不同的角度看待问题,28,OOAD的基本概念：封装,隐藏信息 黑箱操作 降低连锁反应的影响,Buy 100 shares of FM Stocks at market price.,购买者不需要了解实现的具体细节,29,OOAD的基本概念：模块,分块降低复杂性 各部分协同工作,30,OOAD的基本概念：继承,抽象的层次,Asset,Cash,Stock,Bond,Real estate,Commercial,Residential,High

8、er levelof abstraction,Lower levelof abstraction,31,议程,软件架构与模式UML:通用建模语言 OODA:面对对象的分析与设计UML介绍使用案例视图类图表交互图表与行为图表模块与组件组件设计,32,什么是 UML?,统一模型语言(Unified Modeling Language)是一种用来定义，形象表示，创建和文档记载软件系统的工业标准语言。它简化了软件设计的复杂流程，为整个的构架建立一个“蓝图”。,33,为什么使用UML?,一种形象，准确的表达软件功能和结构的标准方法，有效的避免误解 规划者/开发者/测试者/项目经理并不真正了解我尝试规格化

9、的内容 写作规范很费时，但是产品周期越来越短,34,UML 使用在什么地方?,高层的介绍总览的文档/规范规范开发设计文档,35,什么是 UML 图表?,软件系统的蓝图，每个类型的图表都说明了系统的不同的方面软件代码生成的一种方法图形化表示系统如何工作，更快，更好简练易懂的表述，讨论复杂的系统的一种方法,36,UML 图表的类型,使用案例图表行为图表类图表顺序图表,其它类型的UML图表:协作图表数据流图表包装图表状态图表物理图表,37,4+1 视图模式,使用案例视图(“+1”视图)使用案例模型逻辑视图设计模型实施视图实施模型过程视图包括在设计模型中分发视图,38,议程,软件架构与模式UML:通用

10、建模语言 OODA:面对对象的分析与设计UML介绍使用案例视图类图表交互图表与行为图表模块与组件组件设计,39,使用案例,情景,在线消费情景为了一个满足共同的用户的要求，而产生的一系列相互联系的情景使用案例图表辅助作用可以使用其他形式表达行为者与使用案例,及使用案例之间的关系,40,使用案例图表,41,使用案例文本,售票员为顾客买电影票:主要情景:售票员在顾客挑选座次,电影和时间后,为顾客定票.售票员输入顾客的信用卡信息,收取购票费用信用卡认证系统授权交易售票员将票交给顾客扩展情景”1a.顾客是一般顾客:1a1:在保留季节票的前提下销售1a2:顾客可以开始购买季节票1b.顾客持有季节票,1b1

11、:顾客可以使用季节票1b2:顾客也可以够买普通票3a.信用卡授权失败,3a1:售票员可以取消交易,3a2:售票员可以要求顾客提供正确的信用卡信息.,42,使用案例图表,行为者指用户在系统中扮演的角色“行为者”可能是用户，或者另一个系统同一个用户根据扮演的角色,可以成为多个不同行为者在图表中可以只列出主要的行为者或者引起使用案例的行为者使用案例描述“行为者”如何使用系统来达到特定的目标列出行为者可以帮助发现使用案例行为者的细节无关紧要,43,使用案例图表,使用案例之间的关系:包涵,概括,延伸当两个使用案例有重叠的部分时,将重叠的部分独立出来成为一个单独的使用案例,此使用案例包涵于原使用案例当一个

12、使用案例A与另一个使用案例B类似,但有更多的内容时,可以将B作为A的一个特例使用案例,这时,A是B的概括,44,使用案例图表,延伸如果基本使用案例A宣称某些延伸点,使用案例B只在这些延伸点上进行了扩充,B就成为A的延伸使用案例规则使用包含来避免重复的使用案例,使用概括来泛泛描述案例的特殊情况,使用延伸来严格描述案例的特殊情况,45,使用案例的识别,确定使用案例确定对象、参与者的关系与交互在类图表与交互图表中描述细节在逻辑视图中跟踪使用案例危险：步骤太多或者太少。如果在Use Case中有超过15个步骤，它可能包含一些实现明细。如果它只有非常少的步骤则检查它的目标是否是达到一个没有很多分支的活动

13、的单一线索。,46,使用案例的类别,Business Use Case：系统都用于同一商业领域。不假定任何公司内部的结构 System Use Case：整个系统看作是一个黑盒 Implementation Use Case：设计子系统和系统内部组件。每个Use Case只描述没有大的分支的行为的单个线索,47,议程,软件架构与模式UML:通用建模语言 OODA:面对对象的分析与设计UML介绍使用案例视图类图表交互图表与行为图表模块与组件组件设计,48,类图表,什么是类图表？描述了系统中的对象类型，和其相互之间的各种不同的静态联系描述了各个对象属性提示:常在开发中使用,49,类图表,50,定义

14、完善的类,拥有唯一确认的名字，容易识别 代表了类的操作及属性 与其他类协作良好 按照项目或企业的标准命名,51,边界类,在应用程序以及运行环境建立界面包括的方法可以处理用户与应用程序内某个商业流程的交互主要用于界面窗体以及其他与用户交互的建模,52,定义边界类,在使用案例中，每个脚色至少定义一个边界类。脚色可以是外部系统 边界类的最后实现可能是一个ASP页面，也可能是程序窗体,53,控制类,封装了商业逻辑层的的事务复杂性 通常用于在应用过程协调行为在使用案例中控制事件流,Control class name,Control class name,54,定义控制类,每个复杂的使用案例 至少定义一

15、个控制类 控制类相当于一个控制者，不应当关注内部的过程 复杂的使用案例需要更多的控制类,55,实体类,为应用程序存储信息的模型 稳定的数据模型 通常用于商业逻辑层,56,定义实体类,Noun-Verb-Adjective(NVA)方法分析使用案例文档，寻找潜在的实体类确定使用案例的场景，在文档描述中确定句子的主语（名词）将潜在的实体类列出检查使用案例的其他要求或数据字典已确定是否有附加的实体类与客户以及开发人员共同确定最后清单,57,对象的例子,58,服务的例子,59,属性的例子,60,UML 中类图表的表示,类的关联与关系：关联描述了对象之间的协作关系。集合与合成概括实现关联的属性：描述了类

16、的关联的细节。名称脚色浏览方向,61,关 联,表示了类之间的使用关系 包括了两类：”uses a”“knows of a”方向表示了数据之间的交换性,62,议程,软件架构与模式UML:通用建模语言 OODA:面对对象的分析与设计UML介绍使用案例视图类图表交互图表与行为图表模块与组件组件设计,63,交互图表,表示对象类型之间的协作关系对应一个使用案例两种格式顺序图表协作图表表示单一顺序过程,无复杂的条件和循环分支,64,交互图表,顺序图表强调事件间的次序,表示对象类的激活和消灭协作图表强调对象类之间的静态联系弱点对对象类的行为描述不能深入状态图表,65,顺序图表,描述在某一个场景下消息在对象之

17、间按时间顺序的流动消息对象之间的交流只是出消息的流动方向转化为类的方法,66,顺序图表的产生,确定使用案例场景的开始 分步确定在使用案例场景的事件流：创建对象根据步骤创建对象之间的消息确定消息的原型确定消息的参数说明消息的输出,67,顺序图表,68,顺序图表：另一种形式,69,协作图表,以对象为中心的观点 描述对象之间协作的信息 设计者可以看到对象所有接受以及发送的消息 Rational Rose：可以根据顺序图表自动创建,70,协作图表 UML 符号表示,参加者：动作序列的初始点连接：定义了消息在对象之间传递的路径。,71,协作图表的创建,自动 从顺序图表自动产生协作图表 手工在使用案例场景

18、中确定对象创建对象定义对象之间的连接定义对象之间的消息定义消息的原型定义消息的参数,72,协作图表,73,状态转变图表,表示特定对象的所有可能的状态和引起对象状态变化的事件及其条件.在面向对象程序设计中,状态图表通常用来描述某一对象类的全部的行为变化标签:事件 条件/行动状态行为标签:做/行为 其他关键词:总状态 superstate,之后 after,当.when,入口 entry,出口 exit,自迁移 self-transition,74,状态转变图表,75,行为图表,描述了行为的顺序,可以描述复杂的选择性的或并行性的行为是状态图表的一个变化类似于流程图关键词分支 brance,合并 m

19、erge,并行分支 fork,并行合并 join,76,行为图表,77,议程,软件架构与模式UML:通用建模语言 OODA:面对对象的分析与设计UML介绍使用案例视图类图表交互图表与行为图表模块与组件组件设计,78,模块图表,79,模块图表,模块,几个联系紧密的对象类组成的单元模块图表 Package Diagram 在较高层次上表现对象类,或组成部分间的依赖关系.依赖一个组成部分的变化决定与另一个组成部分的变化消息联系,数据关系,参数 无传递性,80,定义模块的指南,找到逻辑上有关联的“类”例如：集合或合成关系考虑外在的系统接口检测系统构造层节点决定元件的版面设计,81,模块和其体系结构,子

20、系统可以用在项目的早期阶段定义高层次应用的体系结构支持“从上到下”的设计方式系统的系统 包含多样化引用的系统每一种引用是整个系统的一个子系统,82,组件,元件物理的、可用二进制表示的应用程序，其中压缩了数据和资料的动态链接的数据库(DLL)可执行的(EXE)可运行一个或以上的界面包含一个或以上的类别,83,组件图表,84,部署图表:描述图,85,UML在程序规范中的应用,使用案例图表忽略了记录详细用户情景和推断他们的需要的步骤行为图表直观的表示了流程和功能类图表定义了对象和属性，以及它们之间的相互关系,86,议程,软件架构与模式UML:通用建模语言组件设计过程三种设计角度概念性设计逻辑性设计物

21、理性设计综合设计,87,讨论,如何进行文档的组织？设计自己的工作方式如何形成良好的工作模式？,88,FM Stock,89,FM Stocks 的结构,AccountSummary.asp,AccountSummary_Client,IAccount,Internet InformationServer and ASP,SQL Server,ActiveX DLL account,Business layer,Presentation layer,Data layer,90,设计,将具体的用户需求转化成具体的编程规范（programming sepcification)的过程,91,设计的演变

22、,概念性设计,逻辑性设计,物理性设计,92,三种设计角度,商务解决方案,概念性,逻辑性,物理性,93,三种设计角度,概念性设计从用户和商务的角度看问题,将问题和解决方案定义场景和使用案例逻辑性设计从设计组的角度看解决方案,从使用案例中，发掘一系列类和服务极其相互配合的关系物理性设计从程序员的角度看解决方案,具体定义解决方案的组件，包装，分布及技术实施,94,4+1 视图模式,使用案例视图(“+1”视图)使用案例模型逻辑视图设计模型实施视图实施模型过程视图包括在设计模型中分发视图,95,议程,软件架构与模式UML:通用建模语言组件设计过程三种设计角度概念性设计逻辑性设计物理性设计综合设计,96,

23、连续设计过程中的概念性设计,概念性设计的目标是用来确定商务需求,了解用户的工作和他们的需求,97,概念性设计,定义获取问题和方案的商务视点和用户视点,加以文档化,并在验证其有效性后进行优化目的获取并理解商务需要和用户需求输出一组用以记录系统现有状态和未来状态的信息模型和应用场景,98,设计者的问题,商务需要或者问题是什么？用户是谁？用户真正做什么？用户的需求是什么？什么是现在已经存在的？什么是最好的解决方案？你如何知道你有了最好的解决方案？,99,澄清概念性设计,概念性设计不是对用户接口的完整的功能性详细描述系统组件的定义技术解决方案,但是使您能够开发部分功能性详细描述设计有效的用户接口了解事

24、情如何协同工作设计商务问题的解决方案,100,概念性设计期间团体中的角色,程序管理,开发,测试,后勤管理,用户教育,产品管理,阐明用户需求,把握整体的设计过程,依照项目使命文档来验证应用场景,识别基于应用场景的输出,考虑与场景相牵连的基础结构,在概念性设计中起主导作用,101,概念性设计的步骤,设计的范围描述核心业务过程和范围，包括业务功能元素业务过程的详细描述描述客户和用户设计的结果确定概念性设计的输入，包括适当的企业架构信息，业务进程和活动，用户和用户原型收集数据，包括商业和用户需求,102,概念性设计的步骤,分析的范围：详细回顾用户和商业研究建立关于内容，工作流以及任务次序的模型信息模型

25、用户案例参与者在系统中通过对话产生的交互行为序列参与者可以为个人，小组，其他系统甚至设备。参与者是针对系统或业务关系而定义的一组关系。用户案例针对下列目标：一个假定的关于参与者和对象的交互序列描述用户使用案例中某个实例的场景。这个场景显示了当前的状态以及一定时期内的变化包括下面四种信息：上下文，工作流，任务序列，物理环境.,103,概念性设计:应用场景,用叙述或图解的方式描述问题和解决方案，使得用户和项目团体成员能够直观地想象并勾画前景提供需求的上下文商务和用户的详细情况通用的观点和通用的词汇表独立于物理实现的设计机会,104,概念性设计目标,基于从商务中和用户处获得的真实数据的设计对于产品连

26、贯的、综合的描述有用的抽象层次或分类层次商务、用户和项目团队中的展望设计中的团体意见与企业架构同步团队交流的基础,105,概念性设计的结果：使用案例,使用案例视图(“+1”视图)使用案例模型,106,FM Stocks概念性设计,FM Stocks的使用案例BuyStock Use Case Create Account Use Case,107,议程,软件架构与模式UML:通用建模语言组件设计过程三种设计角度概念性设计逻辑性设计物理性设计综合设计,108,连续设计过程中的逻辑性设计,逻辑性设计的目标是用以安排解决方案的组织形式以及其各个元素之间的通信,109,逻辑性设计,定义项目团队按照组织

27、、结构、语法以及部件之间的交互关系,对解决方案进行描述的过程目的根据MSF应用模型实施基于服务的组织原则并安排解决方案的结构和其部件间的关联输出一组包含相应服务、属性和关联的对象集，高层次的用户接口设计以及逻辑性数据库设计,逻辑性设计,服务和对象，用户接口，逻辑数据库,110,逻辑性设计期间团体中的角色,在逻辑性设计中起主导作用,确认逻辑性设计是有效的,为服务的改进和关联对象的鉴别提供帮助,解决方案实现的可行性评估,程序管理,开发,测试,后勤管理,用户教育,产品管理,阐明用户的性能目标和推荐的解决方案,保证设计能符合事务和用户的需求,111,组织方法,逻辑系统层次,模块,房子,厨房烹调食物洗盘

28、子存放器具吃快餐,餐厅吃,餐具室储存食物,l,l,l,112,逻辑设计的步骤,分析过程:标识业务对象和服务.标识属性和关系.合理化过程:验证业务对象.验证隐含的业务对象和情境.,113,描述模块,服务独立性能的单位包括方法和功能对象是数据和服务的封装包括属性和方法属性是重要的特性或者对象的值关联对象和服务的入口,服务,对象,关联,模块,114,逻辑性设计的价值,管理复杂度设定边界并描述接口,从而提供一个能使多个组交互的组织结构揭示概念性设计中的错误和矛盾之处消除冗余并确定可能的重用提供物理性设计的基础改进系统的部分运行方式在项目团队成员中建立对于解决方案的通用观点,115,逻辑性设计的结果,逻

29、辑视图设计模型过程视图包括在设计模型中,116,FM Stocks的逻辑设计,通过使用案例文本定义类子系统顺序图与协作图状态图,117,议程,软件架构与模式UML:通用建模语言组件设计过程三种设计角度概念性设计逻辑性设计物理性设计综合设计,118,连续设计过程中的物理性设计,物理性设计的目的是将现实世界中的技术约束，包括实现和性能上的考虑，应用于逻辑性设计之上。,119,物理性设计,定义从开发团队角度描述解决方案的组件、服务和技术的过程目的将现实世界中的技术约束，包括实现和性能上的考虑，应用于逻辑性设计之上输出面向特定平台的组件、用户接口设计以及物理数据库的设计,120,物理性设计期间团体中的

30、角色,评估和验证设计需求,把握整体的设计过程,评估及验证设计的功能性和项目使命的一致性,在物理性设计中起着主导作用,评估和验证设计的基础结构关联,管理用户的期望,程序管理,开发,测试,后勤管理,用户教育,产品管理,121,物理性设计的步骤,研究现有基础设施(infrastructure)的限制解决方案的对基础设施的要求处理要求与限制的冲突带来的风险分析选择用于实施解决方案的技术初步建立部署草图,包括对网络,数据和组件技术合理化决定包装和分布的策略和设计将对象分配到以服务划分的组件中去将组件分配到网络节点上去，形成部署模型使用策略和样板程序，优化部署模型,122,物理性设计的步骤,实施决定编程模

31、型，又称编程规范，编程标准主要考虑因素：见下页具体规定组件的外部结构和界面组件间的合同（contract),获取服务的方式，组件提供的服务，组件包含的类的属性考虑方面：公布的接口将被认为是固定不变的对已存在接口的修改应该被公布为新的组建或者新的接口.公布属性的数据类型应该能够被客户的接口所支持具体规定组件的内部结构考虑方面：编程语言和工具，提高重复使用率等,123,编程模型的各个方面,编程模型的各个方面实现技术有状态与无状态对象进程内与进程外调用连接与无连接模式同步与异步程序模式线程模型错误处理安全分布式,124,物理性设计的价值,评估可供选择的实现提供一个基于组件的灵活设计成为成本、计划和资

32、源估算的基础将解决方案映射成过程模型，用以设计过程中的里程碑或内部的发布改进和修正具有风险的地方寻求与企业架构之间的兼容性通过逻辑性设计使能够跟踪应用场景,125,FM Stocks的物理性设计,实施视图实施模型分发视图,126,FM Stocks的物理性设计,组件设计分发设计,127,MSF 设计原则,理解商务解决商务问题并对产品和服务的分发提供支持有效地同用户及项目团队联系基于模块化的设计在每次迭代中平衡创新和规范与企业架构相结合,128,议程,软件架构与模式UML:通用建模语言组件设计过程三种设计角度概念性设计逻辑性设计物理性设计综合设计,129,MSF设计的特性,综合的迭代并改进的可追

33、踪的高效的,MSF,130,综合性设计,统一观点并平衡需求考虑多种角度和用户概念性设计：用户；管理；商务概念性设计：团队物理性设计：开发者包括多种应用焦点和能力用户接口事务过程数据库,131,经核准的预计,经核准的项目计划,逻辑性设计,物理性设计,概念性设计,迭代并改进的设计,重复一个过程直到达到期望的结果再访问设计的某一部分从每个角色的观点中获取额外的项目详细设计增量调整,132,可追踪的设计,提供满足需求的可见的证明在整个过程中跟踪设计商务预计和目标需求范围 vs.功能预先验证和连续验证初步模型测试和验证基于回馈的再设计,133,高效的设计,使用产品的状态来评估项目基于商务和技术之间的协议，包括：什么是需要构建的是否拥有了足够的信息以启动开发阶段而不是基于：文档的数量会议的数量,134,设计期间团体中的角色,把握整体的设计过程,从用户角度评估和验证设计需求,依照项目的视角和范围来评估和验证设计的功能性和一致性,对商务需求提供技术解决方案,评估和验证设计的基础结构关联,管理客户的期望,程序管理,开发,测试,后勤管理,用户教育,产品管理,135,设计和MSF过程模型,136,Summary,总结,哪些是优秀设计的特性？设计的三个角度是什么？每种角度可发布的内容是什么?如何使设计过程成为综合的？迭代并改进的？可追踪的？高效的？,