UML系统建模与分析设计课后习题答案13
上亿文档资料，等你来发现
UML系统建模与分析设计课后习题答案13
第一章系统建模与分析设计的演变；1、系统建模的三要素：方法、工具和过程；2、软件的分类：；按软件的功能划分：系统软件、支撑软件和应用软件；按软件的规模划分：小型软件、中型软件、大型甚至超；按软件的工作方式划分：实时处理软件、分时处理软件；按软件失效的影响程度划分：一般性软件和关键性软件；3、软件危机产生的原因主要有两个：一是与软件本身；4、软件开发过程模型：
第一章 系统建模与分析设计的演变1、系统建模的三要素：方法、工具和过程2、软件的分类：按软件的功能划分：系统软件、支撑软件和应用软件按软件的规模划分：小型软件、中型软件、大型甚至超大型软件按软件的工作方式划分：实时处理软件、分时处理软件交互式软件和批处理软件 按软件服务对象的范围划分：一次性使用软件和使用频度较高的软件按软件失效的影响程度划分：一般性软件和关键性软件3、软件危机产生的原因主要有两个：一是与软件本身的特点相关；二是软件开发和维护的方法不正确。4、软件开发过程模型：瀑布模型、渐增模型、演化模型、螺旋模型、智能模型5、UML的特点：唯一性、连续性、维护性、复用性和逐步完善6、面向对象的三大重要特征：封装性、继承性和多态性7、软件开发方法从结构化开发方法、模块化开发方法到面向对象开发方法是一个渐进的演变过程8、软件生命周期描述了一个软件从定义、开发、使用、维护到服用的全过程9、面向对象的基本概念有：对象、类急气封装性、多态性、继承性和消息传递10、软件开发过程由客户端需求分析、系统分析、系统设计和系统实现以测试与维护四个四个阶段组成11、面向对象系统的开发过程以体系结构为中心，以用例为驱动，是一个反复、渐增的过程课后习题：ACDB1、 封装是吧对象的属性和操作结合在一起，组成一个独立的对象、2、 封装是一种信息隐蔽技术，目的是使对象的生产者和使用者分离，使对象的定义和实现分开。3、 面向对象方法中的继承机制使子类可以自动地拥有复制父类全部属性和操作4、 使得在多个类中能够定义同一个操作或属性名，并在每一个类中有不同的实现的一种方法是多态性5、软件按照其工作方式可划分为实时处理软件、分时处理软件、交互式软件和批处理软件。6、软件生存周期由软件的定义、软件的开发和软件的使用维护和更新换代三部分组成。7、软件开发模型有瀑布模型、增量模型、螺旋模型、智能模型和快速原型模型等五种主要模型8、 面向对象技术采用以类为中心的封装、继承、多态等不仅支持软件复用，而且使软件维护工作可靠有效，可实现软件系统的柔性制造。9、 UML的优点是：唯一性、连续性、维护性、复用性和完善性。 第二章 统一建模语言UML1、UML的五种视图：用例视图、逻辑视图、构件视图、进程视图和配置视图2、UML的三大类模型图是：用例模型图、静态模型图和动态模型图3、用例模型描述的是外部执行者主要用于需求分析阶段4、UML的静态建模机制包括：类图、对象图、包图、构件图、配置图5、UML的动态模型包括4种兔：状态图、活动图、顺序图、合作图6、软件的开发过程即生命周期划分为开始、详细规划、系统构造、移交四个阶段。7、UML开发过程中的核心活动成分是：分析、设计、实现、测试、配置和一些核心支持活动。8、UML 开发过程的产物包括两大类：模型和文档9、UML软件开发过程的基本特点：用例驱动系统、以体系结构为中心、螺旋上升式的开发过程、以质量控制和风险管理为目标10、UML中的扩展机制包括三种：构造型、标记值和约束。构造型用于对模型元素进行分类，在已有的基本模型元素上定义新的模型元素。标记值也称特性规格说明，他和约束一起直接对摸个模型元素附加一些特性和语义。11、软件项目开发过程包括的具体工作内容是：业务建模、需求分析、设计、实现和测试。12、UML软件开发过程的基本特征是：以用力驱动软件开发全过程，以系统体系结构为中心，以质量控制和风险管理为目标，采用反复迭代、循环、渐增是的螺旋上升式开发过程。 习题：BBCDB1、UML的软件以对象为中心，以系统体系结构为主线，采用循环、迭代、渐增的方式进行开发。2、UML的静态图模型图由类图、对象图、包图、构件图和配置图组成。3、UML的动态模型图由活动图、顺序图、状态图和和作图组成4、UML的最总产物就是最后提交的可执行文件的软件系统和相应的软件文档资料5、在UML的需求分析建模中，用例模型图必须与用户反复交流并加以确认。6、uML分析和设计模型由三类模型图表示，三类模型图是：用例模型图、静态模型图和动态模型图。7、UML的软件统一开发过程，即生命周期按时间顺序可以划分为，开始，详细设计，系统构造和移交四个阶段及阶段中一系列的循环重复。8、UML开发过程是一种二维结构软件开发过程，软件项目开发过程流程包括的核心工作内容是，分析，设计，实现，测试和配置9、UML中的五个不同的视图可以完整地描述出所建造的系统，这五种视图是用例视图、逻辑视图、构件视图、进程视图和配置视图。10、UML中有10中基本图可以完整地描述出所有建造的系统，这10中视图是用例图、类图、对象图、包图、构件图、配置图、序列图、活动图、状态图和合作图。 1、可行性研究：经济可行性、技术可行性和法律可行性。2、需求分析的目的是深入描述软件功能和性能，确定软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求。3、用例图包含的模型元素有系统、执行者、用例以及他们间的不同关系，入继承、关联、依赖等。4、执行者是指在系统外部与系统交互的人或其他系统5、执行者分为“人”执行者和“外部系统”执行者两类。6、UML中用例间的关联主要有4种：继承关联、扩展关联、包含关联和使用关联7、UML的活动图示系统动态行为建模的图形工具之一，用来表示完成一个操作所需要的活动，或者是一个用例实例的活动。活动图实际上也是一种流程图，它描述活动的序列，即系统从一个活动到另一活动的控制流。活动图特别适合秒速动作流和并发处理行为。 习题：BACDB
AA1、可行性研究分析包括经济可行性分析、技术可行性分析和法律可行性分析2、UML的客户需求分析模型包括用例模型、类图、对象图和活动图组成。3、UML客户需求分析使用的CRC卡上责任宜兰的内容主要描述类的属性和操作4、UML客户需求分析产生的用例模型描述了系统的功能要求5、在UML的需求分析建模中，用例模型必须与用户反复交流并加以确认。6、在UML的需求分析建模中，对用例模型中的用例进行细化说明应使用活动图7、活动图中的分劈和同步接合图符是用来描述多进程的并发处理行为8、UML软件开发过程需求分析阶段产生的模型由三类模型图表示。他们是：用例模型图、静态模型图和动态模型图。9、CRC卡中的描述由类名、类特征、类类型、责任和协作者共五部分组成10、软件项目的目的的可行性研究分析中，技术可行性研究包括风险分析、资源分析、技术分析三部分组成11、在UML软件开发过程的需求分析阶段，建立用例模型的步骤分为，确定系统的范围和边界，确定系统的执行者和用例，对用例进行描述，定义用例之间的关系和审核用例模型。12、用例图中以实践方框表示系统的范围和边界，在熊边界内描述的是用例，在边界之外描述的是执行者13、用例模型中的执行者可以是“人”执行者也可以是“外部”系统执行者14、用例模型中的用例之间的关联有使用关联、扩展关联。包含关联和继承关联 1、根据建立的用户需求模型，在系统分析阶段要进一步确立三个模型系统模型：对象静态模型，对象动态模型和系统功能模型。2、类之间的关系有关联、聚集、继承、依赖、细化等。3、包是UML的模型元素之一，包可以包含其他包和类。包之间可以有关系，入依赖等。宝石一种分组机制，他吧一些模型元素组织成语义上相关的组，包中拥有或涉及的所有模型元素叫做包的内容。 习题BBCBB
B 1、 UML的系统分析进一步要确立的三个系统模型是对象静态模型、对象动态模型和系统功能模型。2、 UML的客户需求分析、系统分析和系统设计阶段产生的模型，其描述图符完全不同3、 类和对象都有属性，他们的差别是：类描述了属性的类型，而对象的属性必须有具体值4、 UML系统分析阶段产生的包图描述了系统的系统体系层次结构5、设计模式在面向对象系统设计中是设计方法的一种形式6、“对象容器”设计模式对有限的对象进行管理，它不能修改对象7、在UML软件开发过程系统分析阶段产生的对象模型有三种模型。他们是：对象的静态模型，对象的动态模型和对象的系统功能处理模型。8、 在UML的对象类图中，类之间的关系有依赖、细化、关联、聚集和继承五种。9、 共享聚集的部分对象可以是任何整体的一部分，表示事物的整体/部分关系较弱的情况，整体段的重数应该是n10、在UMl软件开发过程的需求分析和系统分析阶段，建立对象类模型的步骤分为寻找确定对象类、定义接口、定义类之间的关系、建立对象类图和建立系统包图。11、 组合聚集是指整体拥有它的部分，他具有抢的物主身份，表示事物的整体/部分关系较强的情况。部分生存在整体中，不可分离他们与整体一起存在或消亡。整体的充数必须是12、系统分析是在客户需求分析规格说明的基础之上对其进行的分析13、 类有实例，他的实例是一个对象。在UML中，包用来表示一个模型组织的分组机制，包没有实例。 第五章 系统设计与对象动态交互模型1、消息分为四种控制流，分别是简单消息、同步消息、一步消息、和返回消息2、顺序图用来描述对象间的交换行为。他注重消息的时间顺序，即对象间消息的发送和接收的顺序。顺序图还揭示了一个特定场景的交互，即系统执行期间发生在某个时间点的对象之间的特定交互，他适合描述实时系统中的时间特性和时间约束。3、合作图和顺序图都可用来描述系统对象间的交互。顺序图强调的是一组对象间的操作调用的时间顺序，合作图则强调这组对象之间的关系。 习题CCADA1、UML系统设计的一般步骤包括系统对象设计、系统体系结构设计和系统设计的优化2、顺序图和合作图主要用与对用例图中消息流的建模，用他们来描述用例图的行为。3、顺序图的模型元素有对象、消息、链接等，这些模型元素表示某个用例中的若干个对象和对象之间所有传递的消息，来对系统的行为建模。4、顺序图描述一组对象之间消息的传递顺序5、顺序图和合作图建立了UML面向对象开发过程中的对象动态交互模型6、在UML软件开发过程产生的对象动态模型中消息有四种类型，他们是简单消息，同步消息、异步消息和返回消息。7、顺序图和合作图用来表达对象之间的交互，是描述一组对象如何合作完成某个行为的模型化工具8、进程是一个动作流，能够与其他进程并发执行9、线程是内部的一个动作流，能够与其他线程并发执行10、主动对象是一个拥有进程或线程的对象，能初始化控制活动，可以独立并发运行11、被动对象是一个必须由其他对象发来的消息进行触发才执行动作的对象。12、交互图描述系统中对象间的交互行为。每一个交互都有发送者和接受者，他们可以是整个系统、一个子系统、一个用例、一个对象类或一个操作。 包含各类专业文献、文学作品欣赏、各类资格考试、行业资料、应用写作文书、中学教育、外语学习资料、UML系统建模与分析设计课后习题答案13等内容。　
　UML系统建模与分析设计课后题及答案_工学_高等教育_教育专区。主编:刁成嘉南开大学第一章~第七章今日推荐 116份文档 2014一级建造师考试 ... 　UML系统建模与分析设计课后习题去答案_理学_高等教育_教育专区。A1、封装是指把对象的( )结合在一起,组成一个独立的对象。 A.属性和操作 B.信息流 C.消息和... 　UML系统建模与分析设计课后习题_工学_高等教育_教育专区。精心制作1、封装是指把对象的(A )结合在一起,组成一个独立的对象。 A.属性和操作 B.信息流 C.消息... 　UML系统建模与分析设计 刁成嘉 课后答案_信息与通信_工程科技_专业资料。第一章...习题: B 1、可行性研究分析包括经济可行性分析、技术可行性分析和法律可行性... 　uml系统建模与分析设计课后答案_高等教育_教育专区。第一章 一 选择题 系统建模与分析技术的演变 1 封装是指把对象的(A)结合在一起,组成一个独立的对象。 A ... 　系统设计与分析教程uml习题答案 隐藏&& UML 概述 1. 请指出 UML 的三个主要的特性。 1)UML 是一种语言 2)UML 是用来建模的 3)UML 是统一的标准 2. 请指... 　系统分析与设计课后习题答案_计算机软件及应用_IT/计算机...部署图是 UML 唯一能描述系统硬件的图。部署图由...2.动态建模中,活动图建模主要用来做什么? 答: ... 　UML系统建模基础教程习题... 5页 免费 UML系统建模基础教程课后... 暂无评价 ...设计模型:包括高层设计模型和详细设计模型。高层设计模型以架构师为主,系 统分析... 　电子商务系统分析与设计课后习题答案_理学_高等教育_教育专区。第一章一、单选 ...应用: (1)对系统的词汇建模。使用 UML 构建系统最先都是构造系统的基本词汇,...UML建模习题答案song_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
UML建模习题答案song
U​M​L​考​试​,​复​习​提​纲​,​要​点​,​答​案
阅读已结束，如果下载本文需要使用
想免费下载本文？
把文档贴到Blog、BBS或个人站等：
普通尺寸(450*500pix)
较大尺寸(630*500pix)
你可能喜欢一．建模概述
建模的重要性：
建模是开发优秀软件的所有活动中的核心部分，其目的是把所要设计的结构和系统的行为沟通起来．并对系统的体系结构进行可视化和控制。建模是为了更好地理解正在构造的系统，并经常提供简化和复用的机会，同时建模还可以管理风险。
不成功的软件项目失败败原因各不相同，而所有成功的项目的成功原因在很多方面都是相似的：一个成功的软件组织有很多成功的因素，其中共同的一点就是对建摸的采用。
建模是一项经过检验并被广为接受的工程技术：我们建立的房屋和大厦的建筑模型能帮助用户得到实际建筑物的印象：为了分析大风或地震对建筑物造成的影响，我们甚至可以建立数学模型。
人对复杂问题的理解能力是有限的、通过建模，缩小所研究问题的范围。一次只着重研究它的一个方面。这就是几年前讲的&各个击破&的基本方法，即先把一个要解决的难题划分成一系列小问题，解决了这些小问题也就解决了这个难题。此外，通过建模可以增强人的智力，一个适当选择的模型可以使建模人员在较高的抽象层次上工作。
各种工程学科部有其丰富的建模使用历史。这些经验形成了建模的四项基本原理，分别叙述如下
第一，选择要创建什么模型对如何动手解决问题和如何形成解决方案有着意义深远的影响。
第二，每一种模型可以在不同的精度级别上表示。
第三，最好的模型是与现实相联系的。
对软件领域的结构化分析的致命的缺点就是分析模型与系统设计模型没有基本的联系。
第四，单个模型是不充分的。对几个重要的系统最好用一组几乎独立的模型去处理。
根据系统的性质．一些模型可能比另一些模型要重要，例如，对于数据密集型系统．表达静态设计视图的模型将占主导地位；对于图形用尸接口密集型系统，静态和动态用况视图就显得相当重要；在实时系统中，动态进程视图尤为重要；在分布式系统中，例如密集型的应用，实现模型和实施模型是最重要的。
建模的种类
对于软件，有几种建模的方法：最普遍的两种方法是从算法的角度建模和面向对象的角度建模。
传统的软件开发是从算法的角度进行建模，所有的软件都用过程或函数作为其主要构造块。这种观点导致开发人员把精力集中在控制流程和对大的算法进行分解上。除了用这种方法建立的模型是瞻弱的之外，采用这种方法没有其他本质上的坏处．当需求发生变化以及系统增长时，用这种方法建造的系统就变得难以维护。
现代的软件开发采用面向对象的角度进行建模，所有软件系统采用对象或类作为其主要构造块。简单地讲，通常要从问题空间或解空间的词汇中找出对象：类是讨具确共同性质的一组对象的描述。每一个对象都有标识你能够对它命名，以区别于其他付象，状态通常有一些数据与它相联系和行为使你能够该对象做某些事，它也能为其他对象做某些事。
对面向对象系统进行可视化、详述、构造和文档化正是统一建模语言的目的。
仅仅是一种用于构件软件蓝图的标准语言，并且仅仅是软件开发方法的一部分。是独立于过程的，但它贯穿于软件开发生命期，并能表达系统体系结构的各种不同视图，最好把它用于以用况为驱动，以体系结构为中心、迭代及增量的过程中。
像这样的语言的词汇表和规则可以告诉你如何创建或理解结构良好的模型，但它没有告诉你应该庄什么时候创建什么样的模型，因为这是软件开发过程的工作，一个定义明确的过程会绐出如下的指导：决定生产什么制品；由什么样的活动相人员来创建和管理这些制品；怎样采用这些制品从整体上去度量和控制项目。
不仅是一种可视化的、可用于详细描述的语言，还是一种构造语言，它虽然不是一种可视化的编程语言，但用描述的模型可与各种编程语育直接相连，这意味着一种可能性，即可把用描述的模型映射成编程语言，如：、和等。甚至映射成关系数据库的表或面向对象数据库的永久存储。对一个事物，如果表示为图形方式最为恰当，则用，而如果表示为文字方式最为恰当，则用编程语言。这种映射允许进行正向工程：从模型到编程语言的代码生成，也可以进行逆向过程：由编程语言代码重新构造模型。逆向工程并不是魔术：除非你对实现中的信息编码，否则从模型到代码全丢失这些信息。逆向工程需要工具支持和人的干烦：把正向代码生成和逆向工程这两种方式结合起来就町以产生双向工程。这意味着既能在图形视图下工作，又能在文字视图下工作，这需要用工具来保持二者的一致性。
不限于对软件建摸。事实上，它的表达能力对非软件系统连摸也是足够的。例如，立法系统的工作流程，病人保健系统的结构和行为以及硬件设计等。
要学习，一个有效的出发点是形成下述语言的概念模型，这要求学习三个要素：（和是编程语言的作者，他们指出学习一门新的编程语言的唯一方法是用它编写程序，学习也是如此，学习的唯一方法是用它绘制模型）
u 的基本构造块：
事物是对模型中最具有代表性的成分的抽象，关系把事物结合在一起，图聚集了相关的事物。
& 结构事物（）
它们通常是模型的静态部分，描述概念或物理元素，共有种结构事物。这种元素，即类．接口、协作、用况、主动类、构件和节点，是模型中可以包含的基本结构事物，它们也有变体，如参与者、信号、实用程序一种类、进程和线程两种主动类、应用、文档、文件、库、页和表一种构件等。
² 类（）
² 接口（）
² 协作
² 用况（或成为用例）
² 主动类（）
是这样的类，其对象至少拥有一个进程或线程，因此它能够启动控制活动。主动类的对象所描述的元素的行为与其他元素的行为并发，除了这一点之外，它和类是一样的在图形上，主动类很像类，只是它的外框是粗线，通常它包含名称．属性和操作。
² 构件（）
构件和节点是物理事物，前面五种是描述概念和逻辑事物。构件是系统中物理的、可替代的部件，它遵循且提供一组接口的实现。在一个系统中，你将遇到不同类型的部署构件如、构件和，以及在开发过程中所产生的制品构件，如源代码文件。通常构件是一个描述了一些逻辑元素如类、接口和协作的物理包。在图形上，把一个构件画成一个带有小方框的距形，通常在矩形中只写该构件的名称。
² 节点（）
节点是在运行时存在的物理元素，它表示一种可计算的资源，它通常至少有一些记忆能力和处理能力。一个构件集可以驻留在一个节点内，也可以从一个节点迁移到另一个节点。在图形上，把一个节点画成一个立方体，通常在立方体中只写它的名称。
& 行为事物（）
行为事物是模型的动态部分。它们是模型中的动词，描述了跨越时间和空间的行为，共有两类主要的行为事物：
² 交互（）
它由在特定语境中共同完成一定任务的一组对象之间交换的消息组成，一个对象群体的行为或单个操作的行为可以用一个交互来描述。交互涉及一些其他元素，包括消息、动作序列由一个消息所引起行为和链对象间的连接。
² 状态机（）
它描述了一个对象或一个交互在生命期内响应事件所经历的状态序列。单个类或一组类之间动作的行为可以用状态机来描述，一个状态机涉及到一些其他元素，包括状态、转换（从一个状态到另一个状态的流）和事件触发转换的事物和活动对一个转换的响应，在图形上把一个状态画成&个圆角矩形。通常在圆角矩形中含有状态的名称及其子状态。
& 分组事物（）
分组事物是模型的组织部分。它们是一些由模型分解成的&盒子&。在所有的分组事物中，最主要的分组事物是包。包是把元素组织成组的机制，这种机制具有多种用途。结构事物、行为事物甚至其他的分组事物都可以放进包内。包不像构件仅在远行时存在，它纯粹是概念上的，即它仅在开发时存在。在图形上，把一个包画成一个左上角带有一个小矩形的大矩形，在矩形中通常仅含有包的名称，有时还有内容。包是用来组织模型的基本分组事物：它也有变体，如框架．模型和子系统等它们是包的不同种类。
& 注释事物（）
是模型的解释部分，这些注释事物用来描述．说明和标注模型的任何元素。有一种主要的注释事物，称为注解，注解是一个依附于一个元素或一组元素之上、对它进行约束或解释的简单符号、在图形上，把一个注解画成一个右上角是折角的矩形，其中带有文字或图形解释。
& 依赖（）
是两个事物间的语义关系，其中一个事物独立事物发生变化时会影响另一个事物依赖事物的语义。变体有精化、跟踪、包含和延伸。
& 关联（）
是一种结构关系．它描述了一组链。链是对象之间的连接。聚合是一种特殊类型的关联．它描述了整体和部分间的结构关系。在图形上，把一个关联画成一条实线，它可能有方向，偶尔在其上还有&个标记，而且它经常还含有诸如多重性和角色名这样的修饰。
& 泛化（）
它是特殊／一般关系，特殊元素（子元素）的对象可替代一般元素（父元素的对象，用这种方法子元素共享父元素的结构和行为。
指向父元素
& 实现（）
它是类元之间的语义关系，其中的一个类元指定了由另一个类元保证执行的契约。在两种地方要遇到实现关系：一种是在按口和实现它们的类或构件之间；另一种是在用况和实现它们的协作之间。
图（）：包括种图
& 类图（）
类图表现了一组对象、接口、协作和它们之间的关系。在对面向对象系统的建模中所建立的最常见的图就是类图。类图给出系统的静态设计视图，包含主动类的类图给出系统的静态进程视图。
& 对象图（）
对象图展观了一组对象以及它们之间的关系。对象图描述了在类图中所建立的事物的实例的静态快照。和类图一样，这些图给出系统的静态设计视图或静态进程视图，但它们是从真实的或原型案例的角度建立的。
& 用况图（）
用况图展现了一组用况、参与昔一种特定的类及其它们之间的关
系，用况图给出系统的静态用况视图。这些图对于系统的行为进行组织和建模是非常重要的。
& 顺序图（）
& 协作图（）
顺序图和协作图都是交互图。交互图展现了一种交互。它由一组对象和它们之间的关系组成，包括在它们之间可能发送的消息。交互图专注于系统的动态视图。顺序图是一种强调消息的时间顺序的交互图；协作图也是一种交互图，它强凋收发消息的对象的结构组织。顺序图和协作图是同构的，这意崃着它们是可以相互转换的。
& 状态图（）
状态图体现了一个状态机，它由状态、转换、事件和活动组成。状态图专注于系统的动态视图，它对于接口、类或协作的行为建模尤为重要，而且它强调对象行为的事件顺序，这非常有助于对反应式系统建模。
& 活动图（）
活动图是一种特殊的状态图，它展现了在系统内从一个活动到另一个活动的过程。活动图专注于系统的动态视图、它对于系统的功能建模特别重要，并强调对象间的控制流程。
构件图展现了一组构件之间的组织和依赖，构件图专注于系统的静态实现视图。它与类图相关，通常吧构件映射成一个或多个类。
& 实施图（或部署图）
实施图展现了对运行时处理节点以及其中的构件的配置。实施图给出了体系结构的静态实施视图。它与构件图相关，通常一个节点包含一个或多个构件。
u 支配这些构造块如何放置在一起的规则
一个结构良好的摸型在语义上是前后一致的，并且与所有的相关模型协调一致，有用于描述如下事物的语义规则：
命名为事物、关系和图起名
范围给一个名称以特定含义的语境
可见性怎样让其他人使用或看见名称
完整性事物如何正确一致地相互联系
执行运行或模拟动态模型的含义是什么
在软件密集型系统的开发期间所建造的模型往往需要发展变化的方式、在不同的时间进行观察。由于这个原因，下述的情况是常见的，一些结构良好的模型，也要建造一些这样的模型：
省略隐藏某些元素以简化视图
不完全性可以遗漏某些的元素
不一致性不保证模型的完整性
随着系统细节的展开和变动，不可麿免地要出现这些不太规范的模型。的规则鼓励不是强迫你专注于最重要的分析、设计和实现问题，这些问题将促使模型随着时间的推移而具有良好的结构。
u 运用于整个语言的一些公共机制。
由于在中有种贯穿整个语言且一致应用的公共机置使得变得较为简单，这种机制是：
不只是一种图形语言，实际上，在它的图形表示法的每部分背后都有一十规格说明．这个规格说明础供了对构造块的语法和语义的文字叙述；例如，在一个类的图符背后就有一个规格说明：它提供了类所拥有的属性，操作包括完整的特征标记和行为的全面描述。在视觉上，类的图符可能展示了这个规格说明的一小部分。此外，可能存在着该类的另一个视图，其中提供了一个完全不同的部件集台，但是它仍然与该类的基本规格说明相一致。的图形表示法用来对系统进行可视化，的规格说明用来描述系统的细节，假定把二芒分开，就可能进行增量式的建模。还可以通过以下方式完成：先画图，然后对这个模型的规格说明增加语义，或直接创建规格说明，也可能对一个已经存在的系统近行逆向工程，然后再创建作为这些规格说明的投影图。
第一种方法是对类和对象的划分的每一个构造块几乎都存在像类
与对象这样的二分法，例如，可以有用况和用况实例，构件和构件实例，
节点和节点实例。在图形上，刚与类同样的图形符号来表示对象，只是简单地在对象名的下边画一道线，以示与类的区别。
&&三个不同的对象
第二种方法是接口和实现的分离。接口声明了一个契约，而实现则表示对该契约的具体实施，正负责如实地实现接口的完整语义，中，可以既对接口又对它们的实现建摸。几乎每一个的构造块都有象接口和实现这样的二分法。例如，用况和实现它们的协作，操作和实现它们的方法。
实现接口和
提供了一种绘制软件蓝图的标准语言，但是一种闭合的语言即使表达能力再丰富，也难以表示出各种领域中的各种模型在不同时刻所有可能的细微差别，由亍这个原因．是可扩展的，可以以受控的方式扩展该语言，的扩展机制包括：
& 构造型（）
构造型扩展了的向汇，它允许你创造新的构造块，这个新构造块既可从现有的构造块派生，又专门针对你要解决的问题。
& 标记值（）
标记值扩展了构造块的特性．允许你创建上述元素的颗新信息。见上图的类中的＝＝。
& 约束（）
约束扩展了构造块的语义，它允许增加新的坝则或修改现有的觇则。如上图的给方法增加的约束（）。
三、体系结构和开发生命周期
软件体系结构不仅关心结构和行为，而且还关心用法、功能、性能、弹性、复用、可理解性、经济技木约束及其折衷，以及审美的考虑。最终用户、分析人员、开发人员、系统集成人员、测试人员、技术资料作者和项目管理者&&他们各自带着项目的不同日程，而且在项目的生命周期内各自在不同的时间、以不同的角度来看系统。所以要开发不同的系统视图。
u 系统的用况视图（）
由专门描述可被最终用户、分析人员和测试人员看到的系统行为的用况组成。用况视图实际上没有描述软件系统的组织，而是描述了形成系统体系结构的动力。在中，该视图的静态方面由用况图表现，动态方面由交互图、状态图和活动图表现。
u 系统的设计视图（）
u 系统的进程视图（）
u 系统的实现视图（）
u 系统的实施视图（）
体系结构是&组有关下述内容的重要决策：
u 软件系统的组织
u 对组成系统的结构元索及其接口的选择
u 如元素间的协作中所描述的那样的行为
u 将这些结构和行为元素组合到逐步增大的子系统
u 指导这种组织的体系结构风格：静态和动态元素及其他们的接口
种视图中的每一种视图都可单独使用，使不同的人员能专注十他们最为关心的体系结构问题。这种视图也可相互作用，如实施视图中的节点拥有实现视图的构件，而这些构件又表示了设计视图和进程视图中的类、接口、协作以及主动类的物理实现。允许表达这种视图中的任何一种视图，也允许表达它们之间的交互。
在很大程度上是独立于过程的，这意味着它不依赖于任何特殊的软件开发生命周期，然而，为了从中得到最大的收益，应该考虑这样的过程：
u 用况驱动的（）
u 以体系结构为中心的（）
u 迭代的和增量的（）
初始、细化、构造、移交等四个部分迭代。
四、用绘制模型图，详细描述各个构造块及其组合应用
对系统建模涉及到识别出对于你的特定视图来说是重要的事物，这些事物形成了正在建模的系统的词汇表。例如：如果正在建造一所房子，那么像墙、门、窗户、柜厨和灯对于房主来说就是重要的事物。在中，所有的这些事物都被建摸为类，一个类是对作为词汇表一部分的一些事物的抽象。类不是个体对象，而是描述一群对象的一个完整集合。它是一组具有相同属性、操作、关系和语义的对象的描述。
类名有简单名与路径名两种，见上图，一般第一个字母大写，属性名和操作名一般除了第一个单词的第一个字母不大写，其他单词的首个字母大写，如、（）。一个类可以有多个属性也可以没有属性，操作也是如此。属性还可以表明的类型以及初始值，以及只读、共享等特性。操作的特征标记可以标识参数名称、类型、缺省值以及返回类型。
当画一个类时，不必马上把每个属性和操作部显示出来。事实上，在大多数情况下不能这样做有太多的属性和操作以至于不能把它们放在一张图中，也可能不应该这样做，可能只有一些些属性和操作的一个子集与特定的视图相关。由于这些原因，可以对一个类进行省略，这意味着可以有选择地仅显示类的一些属性和操作，甚至也可以不显示任何属性和操作。空栏并不一定意味着没有属性或操作，只是没有选样要显示它们。通过在列表的末尾使用省略号&&&，可以明确地表示出实际的属性和操作比所显示的要多。为了更好地组织属性和操作的长列表，可以利用构造型在每一组属性和操作之前加一个描述其种类的前缀。
职责是类的契约或责任（功能），它是构造型的一个例子。在图形上，把职责列在类图符底部的分隔的栏中，如下图。责职是自由形式的文本，实际上，可以把类的职责写成一个短语，一个句子或一段短文。属性、操作和职责是创建抽象听需要的最常见的特征，事实上，对于大多数要建造的模型，这种特征的基本形式足以传达类的最重要的语义。然而，有时需要可视化或详述其他特征，例如，（对个体的属性和操作进行可视化，对与特定语言相关的操作特性如多态性或一致性进行可视化，甚至对类的对象可能产生或操纵的异常事件进行可视化在中能够表达这些特征以及很多其他特征，但它们被作为高级概念处理。因为有些类是经常出现的，这些抑类的炎是很常见的，并且它们招述了重要的体系结构抽象，所以提供了主动类（表示进程和线程）、构件表尔物理软件构件和节点表示硬件代备等。最后说明的是类很少单独存在。确切地讲当建造模型时，通常要注重于相互作用的那些类群，&般在中，这些类的街体形成了协作，它们常在类图中被可视化。
为了对系统的词汇建模．需做如下工作：
u 识别用户或实现者用于描述问题或解决问题的那些事物，用卡和基于用况分析的技术帮助用户发现这些抽象；
u 对于每个抽象，识别一个职责集。确信要清楚地定义每个类，而且这些职责要在所有的类之间很好地均衡；
u 提供力实现每个类的职责所需的属性和操作。
一旦开始对大量的类建模，就要保证你的抽象提供了一个均衡的职责集。这意味着不能让任何类过大或过小，每一个类应该做好一件事。若抽象出来的类过大，你会发现模型堆以变化且很不容易复用：若抽象出来的类过小，则最后抽象会过多，难以合理地管理和理解。可以使用来帮助你可视化和详述这种职责的均衡。
为了对系统中的职责分布进行建模，要做如下工作：
u 识别一组为了完成某些行为而紧密地协同工作的类；
u 对上述的每一个类识别出一组职责；
u 整体上观察这些类，把职责过多的类分解成轻小的抽象，把职责过于琐碎的小类组合成一个大的类，重新分配职责以使每一个抽象合理地存在。
u 考虑这些类的相互协作方式，相应地重新分配它们的职责，以使得协作中没有哪个类的职责过多或过少。
对非软件事物建模，应该：
u 对被抽象为类的事物建模．
u 如果要将这些非软件事物与已定义的构造型相区别，就要创建一个新的构造型，并用这个构造型详述这些新语义，并给出明确的可视化提示。
u 如果破建模的事物是某种本身包合软件的硬件，考虑把它建模力一种节点，以便能进一步扩充它的结构。
主要用于对软件密集型系统建模，但将它与文本型硬件建模语言如相结合，对硬件系统建模也很有表达力。系统外部的事物通常被描述为参与者。
对简单类型进行建模，应该：
u 对被抽象为类型或枚举的事物建模，这可以用带有适当构造型的类表示符来表示；
u 若需要详述与该类型相联系的值域，可以使用约束。
用约束显示值域，用属性显示枚举值
提示与技巧：
在中对类建模时要记住：对最终用户或实现者来说，各个类都应该映射到某个真实或概念性的抽象：一个结构良好的类，要遵循如下的策略：
u 为取自问题域或解城的词汇中的事物提供明确的抽象。
u 嵌入一个小的、明确定义的职责集，并且能很奸地实现它们。
u 把抽象的规格说明和它的实现清楚地分开。
u 简单而且可理解，并具有可适应性和可扩展性。
当用绘制一个类时，要遵循如下的策略：
u 仅显示在该类的语境中对于理解抽象较为重要的类的特性。
u 通过按种类对属性和操作的长列表分组，来进行组织。
u 把相关的类显示在相同的类图中。
类元是描述结构特征和行为特征的机制。类元包括类、接口、数据类型、信号构件、节点、用况和子系统。中的一些事物没有实例，例如包和泛化关系就没有实例。一般而言，有实例的建模元素被称为类元关联和消息有实例，但与类的实例不完全一样。更重要的是类元有结构特征以属性的形式和行为特征以操作的形式。一个给定的类
元的每个实例共享相同的特征。
属性的可见性：
在中，事物之间相互联系的方式．无沦是逻辑上的还是物理上的，都被建模为关系，在面向对象的建模中，有三种景重要的关系：依赖、泛化和关联都是定义在类这一级的静态事物。在中，通常在类图中对这些关系进行可视化。还有其他两种关系：链（它是关联的实例，描述可能发送消息的对象间的连接）和转换它是状态机中不同状态间的连接。
u 依赖（包括精化、跟踪和绑定）：类之间的使用关系。箭头指向被依赖的事物。依赖可
以带有一个名称，但很少使用，除非模型有很多依赖，并且要引用它们或作出区别，在一般情况下，用构造型区别依赖的不同含义。
u 泛化：父子继承关系。通常（但不总是）子类除了具有父类的属性和操作外，还具有别
的属性和操作，若子类的操作与父类的操作的特征标记相同，则它重载父类的操
作，这称为多态性。一个类可以有个、个或多个父类。把没有父类且最少有
一个子类的类称为根类或基类，把没有子类的类称为叶子类。可以说只有一个父
类的类使用了单继承，也可以说有多个父类的类使用了多继承。泛化很少有名称，
但很少使用。除非模型有很多泛化，而且要引用它们或要加以区别，才需要使用
泛化的名称。
不想让它有任何对象的非叶子类，通常把这样的类称为抽象类。在中，通常把抽象类名写为斜体，以指明这个类是抽象的，如上图中类就是如此。这种规定也适用于操作，如（），这意味着这样的操作提供了一种特征标记，但它是不完全的，因此必须在较低的抽象层次用一定的方法实现。
u 关联：实例之间的结构关系。给定一个连接两个类的关联，可以从一个类的对象导航到
另一个类的对象，反之亦然。关联的两端都连到同一个类是合法的。这意味着，从一个类的给定对象能连接到该类的其他对象。恰好连接两个类的关联叫做二元关联。尽管不普遍，但可以有连接多于两个类的关联，这种关联叫做元关联。
依赖是使用关系．泛化是&&关系，它们都是单向的，而关联描述了类的对象间相互作用的结构路径，关联在缺省的情况下是双向的，但也可以限制它们的方向。
关联有四个修饰：
名称：关联可以有一个名称，用以描述该关系的性质。为了消除名称含义的歧义，可提供一个指引读名称方向的三角形，给名称一个方向。虽然是联可以有名称，但通常不需要给出名称。当要明确地给关联提供角色名时，
或当一个模型有很多关联，且需要对这些关联进行查阅或区别时，则要给出关联的名称。特别是在有多个关联连接相同类的情况下，更要给出关联的名称。
角色：当一个类处于关联的某一端时，该类就在这个关系中扮演了一个特定的角色。角色是关联中靠近它的一端的类对另外一端的类呈现的职责。可以显式地命名类在关联中所扮演的角色。相同类可以在其他的关联中扮演相同或不同的角色。
多重性：关联表示了对象间的结构关系，在很多连接问题中，指明一个关联的实例中有多少个相互连接的对象是很重要的，这个&多少&被称为关联角色的多重性，把它写成一个表示取值范围的表达式或写成一个具体值。就是说明：在关联另一端的类的每个对象要求在本端的类必须有多少个对象，可以精确地表示多重性为、或．．、很多（）、个或很多，甚至可以精确地指定多重性为一个数值如（）。还可以使用象．．．．．．．．．这样的列表来描述更为复杂的多重性，该例的含义是&除了或外的任意数目的对象&。关联的实例叫做链。
聚合：两个类之间的简单关联表示了两个同等地位类之间的结构关系，这意味着这两个类在慨念上是同级别的，一个类并不比另一个类更重要。有时要对一个&整体／部分&关系建摸，其中一个类描述了一个较大的事物&整体&，它由较小的事物&部分&组成，把这种关系称为聚合。它描述了&&的关系，意思是整体对象拥有部分对象。其实聚合是一种特殊的关联，它被表示为在整体的一端用一个空心菱形修饰的简单关联。
和之间的关系为组合聚合关系。表明一个或多个系只能属于一个学校。
提示与技巧：
在中对关系建模时，要遵循如下策略：
仅当被建摸的关系不是结构关系时，才使用依赖；
仅当关系是&&的关系时，才使用泛化；
小心不要引入循环的泛化关系；
往往可以用聚合代替多继承；
一般要保持泛化关系的平衡，继承的层次不道太深，大约多于层就应该想一想。太宽代之以寻找可能的中间抽象类
在对象间有结构关系的地方，要以使用关联为主。
在中绘制关系时，要遵循如下策略：
要一致地使用直线或斜线，直线给出的可视化提示强固了相关事物之间的连接都集中到一个共同争物。在复杂的图中斜线则经常有更好的空间效果。在同一个图甲使用两种线形有助于把人们的注意力引导到不同的关系组。
避免线段文又；
仅显示对理解特定的成组事物必不可少的关系，应该省略多余的关系，特别是多余的关联。
三公共规范
u 注解（）是附加在元素或元素集上用来表示约束或解释的图形符号，在图形上，把注解画成带有摺角的矩形，在矩形中填写文字或图形注释。表示注释的注解对模型没有什么语义影响，这意味着它的内容不会改变它所依附的模型的含义，这是为什么用注解描述像需求、观察资料、评论和解释之类事物的原因，也是用注解表示约束的原因。
u 构造型（是的词汇的扩展，允许创建与已有的构造块相加而针对特定问题的新种类的构造块。在图形上，把构造型表示成用书名号括起来的名称，并把它画在其他的元素名之上。作为一种选择，可以用一种与构造型相联系的新图形表示被构造形化的元素。新构造块有自己的具体特性（各构造型可以提供自己的标记值集）、语义各构造型可以提供目己的约束和表示法各构造型可以提供自己的图标。
u 标记值（）是对元素的特性的扩展，允许在元素的规格说明中创建新的信息。在图形上，把标记值表示成用花括号括起来的字符串，并把它放在其他的元素名之下。最简单的形式是把标记值表示成一个由括号括起来的串，并放在另一个元素的名称之下，这个串包括一个名称标记、一个分隔符和一个（标记的）值。
u 约束是对元素的语义的扩展，允许增加新的规则或修改已有的规则，在图形上，把约束表示成用大括号括起来的字符串，并把它真在关联的元素跗近，或者通过依赖关系连接到这个（或这些元素）。作为一种选择，可以在注解中表示约束。可以把约束写咸自由形式的文本。若要更精确地详细语义，可以使用的对象约束语言。如下图：
u 修饰大多数修饰是通过在感兴趣的元素附近放&些文字或对基本表示法增加图形符号表示的。然而，有时要用比简单文本或图形符号更能提供细节的事物来修饰元素，诸如类、构件和节点这佯的事物，可以在它们通常的分隔栏的底部增加分隔栏，以填写这种信息。除非分隔拦的内容很明显，否则最好对任何分隔栏都显式地命名，以避免含义混淆。此外还建议尽量少使用分隔栏、因为若过度地使用，会造成图形混乱。
要对注释建模，要遵循如下策略：
u 把注释文本放人注解内，并把该注解放于它所对应的元素附近。可以用依赖关系把注解与对应的元素相连接，以更明确地表明关系。
u 要记住，可以按需要隐藏或显示模型中的元素。这意味着不必到处显示可视化的元素上
的注释，而只有在语境中需要交流这种信息时才显示图中的注释。
u 如果注释冗长或者包含比纯文本更复杂的事物，可考虑把注释放在外部的文档中，并把文档连接或嵌入到依附于模型的相应注解中。
u 当建模演化时，保持那些有意义的记录结果，并且这些结果不能从模型本身导出，无保留价值的注释。
当绘制构造型、标记值或约束时，要遵循如下策略：
u 要确认用基本的无法表达你要做的事情，如果是常见的建模问题，可能已存在一些标准的构造块、标记值或约束可满足你的需要，如果确信没有已经存在的方法能表达这些语义，才创造新的构造型、标记值或者约束。
u 要少用图形构造型，你可以用构造型完全改变的基本表示法，但这样做可能会使其他任何人都不理解你的模型；
u 对图形构造型，可以考虑使用简单的颜色或阴影，也可使用较复杂的图标，简单的表示法一般来说是最好的，即使是最单薄的可视化提示对于理解其含义也大有帮助。
图是观察类、接口、构件等基本构造块的方式。图是一组元素的图形表示，经常把大多数图表示成顶点事物和弧（关系）的连通图。用来从不同的角度对系统进行可视化，因为没有哪个复杂的系统能仅从一个角度理解其全局，所以定义多种图，使你能分别独立地注重于系统的不同方面。优秀的图使得正在开发的系统易于理解和处理，选样一组正确的图来对系统进行建模，能促使你对系统提出正确的问题，并有助于表明决策的含义。
在软件方面，对软件体手结构进行可视化、详述、构造和文档化，有种最重要的互补视图：用况视图、没计视图、进程视图、实现视图和实施视图，每一种视图都包含结构建模对静态事物建模和行为建模（对动态事物建模）。当用从任一角度观察软件系统时，要用图去组织感兴趣的元素。定义了种图，可以混合和组配它们来汇集成各种视图例如，系统的实现视图的静态方面可以用构件图可视化；同一个实现视图的动态方面可以用交互图可视化。类似地，系统数据库的静态方面可以用类图可视化；动态方面可以用协作图可视化。当然，你可以不限于这种图，在中，定义这种图是因为它们表示了被观察元素的最常见的组合。为了适应项目或组织的需要，可以创建你自己所需种类的图，从而以不同的方式对元素进行观察。
静态图：类图、对象图、构件、实施图
动态图：用况图、顺序图、协作图、状态图、活动图
*******************************************************************************
在实践中创建的所有图都是两维的，这意味着它们都是绘制在纸上、白板上、信封的背面或计算机显示器上的，节点和弧的平面图。UML允许创建三维图，即有深度的三维图，允许在模型中&漫游&，一些虚拟现实研完组己显示了这种UML的高级用法。UML许创建动态图，并且允许使用颜色和其他的可视提示去&运行&图，一些工具已经展示UML的这种高级的用法。
系统、子系统、模型、视图、图的概念（要仔细品味区别）：系统是一个为完成一定的目的而被组织起来的子系统的集合，这些子系统由一组可能来自不同观点的模型描述；子系统是一组元素的组合，其中的一些元素构成了其他被包含的元素所提供的行为规格说明；模型是系统的语义闭合的佃象，这意味着它表示对现实的简化，这种简化既是完整的又是自相容的，这是力更好地理解系统而建立的。在体系结构的语境中；视图是对系统模型的组织和结构的投影，注重于系统的一个方面。图是一组元素的图形表示，通常表示成由顶点事物和弧关系组成的连通图。
l 构建类图
类图显示了一组类、接口、协作以及它们之间的关系，是面向对象系统建模中最常见也最重要的一种图，是构件图和实施图的基础，它对系统的静态设计进行建模，大部分涉及系统的词汇建模、协作建模和模式建模。类图不仅对结构模型的可视化、详述和文档化很重要，而且对通过正向与逆问工程构造可执行的系统也很重要。
类图一般包含：
& 依赖、泛化和关联等关系
& 有时还有实例
设计视图主要在三个方面使用类图：
对系统的词汇建模
对简单的协作建模
对逻辑数据库的模式建模
使用的某些功能，所创建的模型将永远不会映射成代码：刨如，若用活动图对业务过程建模，则很多被建模的活动要涉及列人员而下是汁算机，另一种情况是你所建模的系统的组成部份在你的抽象层次上只是一些硬件虽然在另一个抽象层次上看，也可以说该硬件包含了嵌入的计算机的软件
在大多数情况下，要把所创建的模型映射成代码。没有指定对任何面向对象编程语言的映射，但还是考虑了映射间题。特别是对类图，可以把类图的内容清楚地映射到各种工业化的面向对象的语言，如．＋＋，，，，和。也可以被设计得可映射到各种商用的基于对象的语言，如。
正向上程是通过到实现语言的映射而把模型转换为代码的过程。由于用描述的模型在语义上比当前的任何面向对象编程语言都要丰富，所以正向工程将
导致一定信息的损失。事实上，这是为什么除了代码之外还需要模型的主要原因，像协作这
样的结构特征和交互这样的行为特征，在中能被清晰地可视化，但源代码就不会如此清晰。
逆向工程是通过从特定实现语言的映射而把代码转换为模型的过程。逆向工程会导致大量的多余信息，其中的一些信息属于细节层次，对建造有用的模型来说过于详细。同时，逆向工程是不完整的。由于在正向工程中产生的代码丢失了一些信息，
所以，除非所使用的工具能对原先注释中的信息这超出了实现语言的语义进行编码，否则就不能再从代码创建一个完整的模型。
对类图进行正向工程，要遵循如下的策略：
u 识别映射到所选择的实现语言的规则，这是你要为整个项目或组织做的事情。
根据所选择语言的语义，可能要限定对一些特性的用法。例如，允许对多继承建模，但和都仅允许单继承。可以选择禁止开发人员用多继承建模这使得模型依赖于语言，也可以选择把这些丰富的特征转化为实现语言的惯用方法这样使得映射更为复杂。
u 用标记值详述目标语言。如果需要精确的控制，可以在单个类的层次上做这些事情，也可以在较高的层次上如协作或包这样做。
u 使用工具对模型进行正向工程。
对类图进行逆向工程，要遵循如下的策略：
u 识别从实现语言或所选的语言进行映射的规则。这是你要为整个项目或组织做的事。
u 使用工具，指向要进行逆向工程的代码，用工具生成新的模型或修改以前进行正向工程时已有的模型。
u 使用工具，通过查询模型创建类图。例如，可以从一个或几个类开始，然后通过追踪特定的关系或其他相邻的类扩展类图。根据表达你的意图的需要，显示或隐藏类的内容的细节。
为了由不同的视图对系统建模，要遵循如下的策略：
u 决定你需要哪些视图才能最好地表达系统的体系结构．并暴露项目的技术风险，上面描述的种体系结构视图是一个好的开始点。
u 对这样的每种视图，决定需要创建哪些制品来捕获该视图的基本细节，在大多数情况下，这些制品由各种图组成。
u 作为你的过程策划的一部分，决定你将把哪些图置于某种形式或半形式的控制之下。对这些图要安排复审，并把它们作为项目的文档保存。
u 允许保留废弃的图，这些临时图仍然有助于探究决策的意图，也有助于用情况变化进行实验。
可以对同一模型或不同的模型创建几种图，每种图掩盖或显露不同的元素集，并显示不同层次上的细节，即抽象层次，以达到不同的参与者之间交流目的（比如，程序员工作在较低的抽象层，而系统分析员和用户工作在较高的抽象层）。
在不同的抽象层次对象统建模，要遵循如下的策略：
u 考虑读者的需要，从给定的模型开始；
u 如果读者要用这个模型构造实现，就需要较低抽象层次的图，这意味着需要揭示许多细节；如他们用这个模型向最终用户提供概念模型，就需要较高抽象层次的图，这意味着需要隐藏许多细节。在不同的抽象层次的模型之间进行跟踪依赖。
用况及其实现：用况模型中的用况要跟踪到设计模型中的协作；
协作及其实现：协作要跟踪到共同工作以完成协作的一组类；
构件及其设计：实现模型中的构件要跟踪到设计模型中的元素；
节点及其构件：实施模型中的节点要跟踪到实现模型中的构件；
u 根据你在这个从低到高的抽象层次谱系中所处的位置，通过隐藏或揭示模型中的如下种事物，而在恰当的抽象层次上创建图：
构造块和关象：把与图的内容无关的或读者不需要的构造块和关系隐藏起来；
修饰：仅仅显示对于理解意图是必要的构造块和关系的修饰；
流：在行为图的语境中，仅展开对于理解意图是必要的那些消息或转换。
构造型：在用于属性和操作等单物的分类列表的构造型的语境中，仅显示对于理解意图是必要的那些构造块的项。
参看下列两个不同抽象级别的交互图：
对于复杂视图建摸．要遵循如下的策略：
u 首先要确定不存在任何没有意义的方法，能用于在较高的抽害层次上表达这种信息，或许要省略一部分图，并抑制其他部分的细节；
u 如果已经隐藏了能够隐藏的细节，但图仍然是复杂的，就考虑把一些元素组织到&些包或者层次较高的协作中，然后仅把这些包或协作画在图中；
u 如果图仍然是夏杂的，就用注解和色彩作为可视化提示，以将用户的注意力引导到你所强调的重点上
u 如果图还是复杂的，把它全部打印出来，挂在适宜的大墙上。虽然丧失了联机形式所带来交互性，但能够退后&步研究它的公共模式。
阅读(...) 评论()