软件开发与项目管理-_软件开发与项目管理_工具使用手册_rationalsoftwarearchitect使用手册内容摘要:

)展示了可能包含许多模型的建模项目。 模型(本身就是模型元素)包含相应的模型元素,例如包、类、参数、方法和约束。 在 Model Explorer 中,您可以添加、删除、分类,并组织元素,您还可以在图编辑器中打开 UML 图。 图 7. Model Explorer 视 图 Navigator Diagram Navigator 是工作区中不同的项目视图。 它在目录(树型)视图中显示建模项目、 UML 模型,及其 UML 图,如 图 8 所示。 图 8 Diagram Navigator 视图 UML 图帮助您可视化并控制模型中的元素。 不同的图表示您正在开发的系统、应用程序,或数据库的不同视 图。 因为图可以说明模型的多个方面,所以同样的模型元素可以出现在一个或多个图中。 UML 利用许多涉众公认的标准标记,提供让用户获取并传达应用程序架构所有方面的各种图。 这些是 13 个正式的 UML 图,每一个都表示系统的不同方面:  活动图: 活动图提供对系统行为的视图,它描述了过程中的活动序列。 除了展示活动中动作之间的流,类似流程图,活动图还可以展示并行或并发的流,及交替的流。  类图: 您可以使用类图来对组成系统的对象建模,展示对象之间的关系,以及描述那些对象要做什么,及它们要提供什么服务。 类图对对象 建模过程是很重要的,并且在分析和设计阶段是有用的。  通信图: 原来在 UML 1 中称为协作图,通信图展示了对象之间的消息流,并且展示了若干对象如何一起合作实现共同目标。 类似于序列图,通信图也对用例的动态行为建模。 然而,通信图更看重对象的协作,而不是时间序列。  组件图: 组件图展示了系统组件之间的结构关系。 在 UML 2 中,组件是系统或子系统中自治,封装的单元,它提供一个或多个接口。 因此,组件图能够让架构师来验证,组件在实现系统的所需功能。  复合结构图: 复合结构图探索了在通信链路上协作的连通实例的运行时 实例。  部署图: 部署图描述了处理节点的运行时配置,以及运行于那些节点(系统的硬件、安装在硬件之上的软件,以及连接不同机器的中间件)之上的组件的静态视图。  交互总览图: 交互总览图是活动图的变体,它当中的节点表示交互图。 交互图包含序列、通信、交互总览,及时序图。  对象图: 使用对象图来探究对象的真实世界的实例,以及它们之间的关系。 对象图类似于类图,因为关系的标记是一样的。 要解释对象之间复杂的关系,对象图是很好的选择。  包图: 包图可以让您将模型元素组织为用文件夹表示的组,这使 UML 图更容易理解。  序列 图: 序列图说明了交互中对象之间消息的时间序列。 它包含参与者小组,例如角色、系统或子系统、类,和用生命线表示的组件,以及交互过程中交换的消息。  状态机图: 状态机图描述了对象所处的各种状态,以及那些状态之间的变迁。  时间图: 时间图探究了具体的时期中一个或多个对象的行为。  用例图: 使用用例图来可视化(或例举)用例和角色之间的关系,以及用例和其他用例之间的关系。 Diagram Editor 您可以由 Diagram Navigator 或 Model Explorer 视图在 Diagram Editor 中打开 UML 图( 图 9)。 您可以同时选择打开多个图,然后使用选项卡在打开的图之间切换。 UML 图包含许多图元素。 图元素 ,也称为 图形 ,是表示 UML 元素(例如类、接口,和关系),或者没有 UML 语义的几何形状(例如椭圆形、菱形和矩形)的图形或文本元素。 在 Diagram Editor 中,您可以从 Model Explorer 中将现有的模型元素拖拽到图中,或者您可以使用选项板来创建新的图元素。 (如果图元素表示 UML 元素,那么其相应的 UML 元素将被添加到模型中。 ) 图 9. Diagram Editor 视图 属性( Properties) 如果您选择 UML 图中的图元素,您可以在 Properties 视图中看到并设置该图元素的属性( 图 10)。 属性是控制 UML 图中图形和连接件的特征的值。 例如,每个图形和连接件都有一个线条颜色属性,您可以通过它指定图形的边或者连接件的线的颜色。 您还可以指定属性值,从而改变连接件的线条样式,以及显示或隐藏间隔或间隔标题。 如果您在 Model Explorer 中选择模型元素,那么您可以看到并设置模型元素的属性,例如名称和可视性、模型的概要文件,和类的属性及方法。 图 10 Properties 视图 Rational Software Architect 包含用例、分析和设计模型的模板。 每一个都针对不同的开发阶段:需求、分析和设计。 Rational Software Architect 不为表示实现的物理组成的实现模型提供模板,包括实现子系统和实现元素(源代码、数据和可执行文件)。 不包含实现模板的原因是 Rational Software Architect 的操作理论是:通过设计使用平台无关的模型,然后通过各种不同的转换,让 Rational Software Architect 把这些设计转换为代码或实现级工件。 用例模型提供有关您正在开发的系统或应用程序的行为的详细信息。 它根据为实现目标或解决用户所确定的问题而必须存在的功能,确定出系统的需求(用例),并且指定周围环境(角色)和用例与角色之间的关系(用例图)。 用例模型还包括描述用户与系统如何交互的用例图和活动图。 分析模型描述了您正在建模的系统或应用程序的结构。 它包括了描述用例模型中所确定的功能需求的逻辑实现的类和序列图。 分析模型确定出系统中的主要类,并且包含一组描述系统如何构建的用例实现。 类图通过利用原型对系统的功能部分建模对系统的静态结构进行描 述。 序列图通过描述用例中事件执行时的流对用例进行实现。 这些用例实现对系统的一些部分如何在具体用例环境中交互进行建模。 分析模型描述了系统的逻辑结构,因而它是设计模型的基础。 设计模型是基于分析模型的,它向系统的实际实现中添加了详细信息。 设计模型通过使用各种图(包括序列图、状态机图、组件图和部署图),详细地描述了应用程序是如何构成,以及如何实现的。 它还描述了程序设计构想及技术,例如那些用于持久性、分布、安全,及记录的内容。 设计模式通常对设计模型进行提炼,从而获取经常使用的,或复杂的结构和过程。 如前面设计模型部分中所提到的,您可以利用设计模式对设计模型进行提炼(修改或添加 UML 元素),从而将解决方案应用到已知问题上。 您可以利用 Rational Software Architect 的模式框架来完成许多重要的任务:  撰写模式。
阅读剩余 0%
本站所有文章资讯、展示的图片素材等内容均为注册用户上传(部分报媒/平媒内容转载自网络合作媒体),仅供学习参考。 用户通过本站上传、发布的任何内容的知识产权归属用户或原始著作权人所有。如有侵犯您的版权,请联系我们反馈本站将在三个工作日内改正。