UML建模技术4系统概要设计中的UML静态建模.ppt

UML建模技术4系统概要设计中的UML静态建模.ppt

《UML建模技术4系统概要设计中的UML静态建模.ppt》由会员分享，可在线阅读，更多相关《UML建模技术4系统概要设计中的UML静态建模.ppt（52页珍藏版）》请在冰豆网上搜索。

1,提问,RUP“4+1View”分别是哪5个架构视图？

系统的可扩展性与系统的可伸缩性有何异同？

Scal-Up与Scal-Out有何异同？

谈谈你对SOA架构和RESTful架构的认识REST（RepresentationalStateTransfer）表述状态转移（或代表状态传输），它代表了分布式超媒体系统的体系结构风格。

在Web世界中，REST接口是由HTTP接口定义的，支持基本的应用程序方法：

GET。

POST，PUT和DELETE。

（除了这基础的四个方法外，HTTP没有其他的方法。

）这种统一接口限制，跟面向服务体协结构风格（SOA）相反，后者为每种类型的服务定义了不同的接口。

“如果REST是一种风格，那么以资源为导向的架构就是这种风格的一种实现，就好像如果面向对象编程是一种风格，那么Java就是一种实现一样。

“资源导向型架构就是是应用到真实世界的REST。

”,1,第四章系统概要设计中的UML静态建模,于千城yu_15209515074,3,静态建模的目的,获得描述软件系统模型的静态结构和各个组成元素之间的关系，即模型的内部组成特性及其相互之间的关系。

静态建模是动态建模的基础UML中，可以通过用例图、组件图、包图、类图、部署图来可视化地描述系统模型的静态结构,3,4,提纲,4.1UML组件图4.2UML包图4.3UML类图,4,5,4.1UML中的组件及组件图,UML中的组件组件一般用于表示实际存在的、物理的物件，它是软件系统的一个物理单元，代表系统的一个物理实现块。

组件图的作用描述软件系统中各个组件之间的关系，并能够帮助客户理解最终的系统结构每个组件图只是系统实现视图的一个图形表示，只有各个组件图组合起来，才能表示完整的系统实现视图。

组件图能够帮助开发组中的其他人员（如文档人员）理解整个系统的组成关系。

组件图中的三大组件边界组件、控制组件、实体组件,5,6,ComponentStereotype,MainProgramThiscomponentrepresentsafilethatcontainstherootofaprogram.SubprogramSubprogramcomponentscorrespondtosubroutinedeclarations.Subprogramsgenerallycontainsingleorgroupedsubroutines;theydonotcontainclassdefinitions.,6,7,ComponentStereotype,PackageSpecificationInC+,youcanusethepackagespecificationtorepresentthe.hfile.PackageBodyInC+,youcanusethepackagebodytorepresentthe.cppfile.,7,8,ComponentStereotype,TaskTaskcomponentsrepresentpackageswithindependentthreadsofcontrol.Iftasksarecompileddifferentlythanregularpackages,youcanallocateaclassdefinitiontoatask.EXEAcomponentofthetypeEXErepresentsanexecutable（.exefile）.DLLADLLcomponentstereotyperepresentsaDataLinkLibrary（a.dllfile）.,8,9,4.1UML中的组件及组件图,组件在UML中的图示组件图由组件、接口和组件之间的联系构成，其中组件可以是源程序代码、二进制代码或可执行程序。

组件之间可以存在依赖联系一个组件的模型元素如果使用了另一个组件的模型元素或者组件实现了某个接口，则此时这两个组件之间就产生了依赖关系adependencyrelationshipfromacomponenttoanothercomponent.Orfromacomponenttoaninterfaceofanothercomponent建立一个可执行系统组件图的步骤确定项目中的各个组件，并对对应的组件加上必要的构造型描述；确定组件之间的联系，一般通过实现接口产生依赖关系；把组件组织成对应的包，并绘制出对应的组件图,9,10,Rose2003下的组件图建模和正向工程,添加javaadd-ins将java设为project的defaultlanguang将java设为Model的defaultlanguang将一个或多个class指定给一个组件生成javacode,10,11,UML规范中关于组件图的定义,在UML中，组件（也叫构件）是一个较模糊的概念，因为类和组件都可用来对同一事物建模。

结构化的类和组件之间的区别很模糊，通常取决于使用者的意愿而非严格的语义UML规范OMG03b的定义：

组件表示封闭了其内容的系统模块，它在其环境中的表现形式可以被替代。

组件通过所提供的和所需要的接口定义了其行为。

同样，如果组件作为类型，那么它的一致性是通过这些所提供的和所需要的接口来定义的。

使用组件的建模和设计意图是为了强调：

接口是重要的它是自包容和可替换的模块。

这意味着组件很少或不依赖于其他外部元素（可能除了标准核心库）组件是设计级别的视图，并不存在于具体软件视图。

但可以映射为具体的软件制品（例如一组文件）,11,12,UML大师们关于组件图的观点,由于基于构件的建模所强调的是可替换性（可能改善了诸如性能这样的非功能品质），因此其一般准则是，为相对大型的元素进行构件建模，因为对大量较小的、细粒度的可替换部分进行设计较为困难。

一个较好的类比是家庭娱乐系统：

我们期望能够轻易替换DVD播放机或扬声器。

它们是模块化的、自包容和可替换的，并且通过标准接口相互连接。

再比如，在粗粒度级别上，SQL数据库引擎可以被建模为构件（任何理解相同版本SQL语言并且支持相同事务语义的数据库之间可以相互替换）；在较细粒度的级别上，任何实现标准JMS（JavaMessageService）API的解决方案在系统中都可以相互替换,12,13,StarUML下画这个组件图,13,14,提纲,4.1UML组件图4.2UML包图4.3UML类图,14,15,Rose2003下画Blog系统的包图,15,16,Rose2003下画Blog系统的带接口的包图,16,17,提纲,4.1UML组件图4.2UML包图4.3UML类图,17,18,4.3.1UML中的类图,类图类图表达了实现某一用例中一组对象类之间的静态结构，以及它们之间的联系与交互关系类图的作用描述系统的静态结构和关系。

不仅定义系统需要的各个类，还能够表示类之间的关系（关联、依赖、聚合、组合、泛化、实现），还定义和描述了类的内部结构（类名、属性、操作）类之间的关系结构性关系（静态组成关系）父类与子类之间的泛化/特化类与类之间的关联、依赖、聚合、组合、实现行为性关系类之间可以通过消息联系，通过系统预定义和用户自定义的语义进行联系,18,19,4.3.1UML中的类图,类的UML图示名称：

每个类都有一个惟一的名称，通常采用CamelCase格式表示属性：

是已被命名的类的特性，它描述该类实例中包含的信息操作：

是类所提供的服务，它可以由类的任何对象请求以影响其行为属性名和操作名也通常采用CamelCase格式表示，只不过首字母通常为小写。

在英语中，依靠单词的大小写拼写复合词的做法，叫做“骆驼拼写法”（CamelCase）。

这种拼写法在正规的英语中是不允许的，但是在编程语言和商业活动中却大量使用。

19,20,UML类图示例,20,21,分析类图和设计类图,类图既可以用于概念透视图，也可以用于软件透视图。

用分析类图（AnalysisClassDiagram，ACD）表示在概念透视图中的类图（领域模型和鲁棒图都属于ACD）用设计类图（DesignClassDiagram，DCD），表示在软件透视图和设计透视图中的类图对领域模型使用类图时，需要表示关联名称，但是要避免使用导航箭头，因为领域模型不是软件透视图,21,22,类之间的关联关系,关联关系（Association）关联是一种结构化的关系，指一种对象和另一种对象有联系。

它是对具有共同结构特性、行为特性、关系和语义链接的描述。

关联用一条实线将类连接在一起，若是单向关联，则在关联端加箭头表示方向，双向关联无箭头。

箭头由源对象指向目标对象，表示源对象的一个属性是目标对象。

多重性和角色名一般放在目标一端。

关联的重数两元关系：

一对一的关系多元关系：

一对多、多对一、多对多的关系关联端的多重性规定了该类中有多少个对象参与了该关联关联的名称,0.1:

表示0到1个对象1：

表示1个对象0.*:

表示0到多个对象1.10:

表示1到10个对象,22,23,Blog系统的类图,23,24,User类java代码,24,25,Blog类的java代码,25,26,表示UML属性的方式,属性可见性：

如果没有给出可见性，则通常假设可见性为私有的,26,27,准则：

何使用属性文本，何时使用关联线,应用准则，以两种表示法展示属性,对数据类型对象使用属性文本，对其他对象使用关联线,27,28,如何使用属性文本和关联线表示集合属性,使用特性字符串：

ordered,List等,28,29,类之间的依赖关系,依赖关系（Dependency）依赖关系体现类之间的“使用和调用”关系，指特定事物的改变有可能影响使用该事物的事物，反之不成立。

通常情况下，依赖关系体现在目标类的对象出现在局部变量或者方法的参数中以及静态方法的调用。

依赖关系总是单向的。

依赖关系示例某一个类使用了另一个类的对象作为操作方法中的参数,29,30,如何在类图中表示方法体,混合了动态视图和静态视图,在类图中，使用构造型为method的UML注解符号,30,31,类之间的依赖关系,依赖关系示例一个类存取另一个类中的全局对象一个类调用另一个类中类作用域的操作方法,31,32,作业和第一次实验报告评价,软件项目中开发文档的重要性答：

项目实施过程中所做出的重大决策必须以开发文档的形式记录下来项目验收时开发文档是必须的交付物开发文档有助于项目组成员间的交流沟通开发文档有助于用户更好地理解和使用系统开发文档是进行知识管理的重要手段,32,33,作业和第一次实验报告评价,33,34,作业和第一次实验报告评价,34,35,作业和第一次实验报告评价,35,36,作业和第一次实验报告评价,36,37,作业和第一次实验报告评价,37,38,作业和第一次实验报告评价,38,39,作业和第一次实验报告评价,39,40,作业和第一次实验报告评价,40,41,作业和第一次实验报告评价,41,42,关于依赖关系的进一步说明,依赖（dependency）关系表示：

客户元素（任何种类、包括类、包和用例等）了解其它的提供者元素，并且表示提供者有所改变时会对客户产生影响。

依赖可以视为耦合（coupling）的另一个版本：

即某元素耦合或依赖于另一个元素。

一般来说，只要出现以下情形，则类之间必有依赖关系拥有提供者类的属性向提供者发送消息。

对提供者的可见性可能是：

属性、参数变量、局部变量、全局变量或类的可见性（调用静态或类方法）接收提供者类的参数提供者是超类或接口所有这些类型在UML中都可以用依赖线表示，但是其中有些类型已经具有了暗示依赖的特殊线条表示法，如：

超类、接口实现、以关联关系表示属性的线。

所以，在这些情形下不需要再使用依赖线何时表示依赖在类图中，使用依赖线描述对象之间的全局变量、参数变量、局部变量