石振莲 软件学院308 67396121 zshi@bjut.edu.cn 可视化建模与UML 石振莲 软件学院308 67396121 zshi@bjut.edu.cn

About me 学士 硕士 工程师

About me Master of Science University of Pittsburgh SQA Engineer

E_Mail: zshi@bjut.edu.cn Contact Me Name：Zhenlian Shi 石振莲 Office：SSE 308 Tel：67396121 E_Mail: zshi@bjut.edu.cn

课程安排 Week 1-12 ，Thursday 9:45-11:30am The First Teaching Building Room 234

Prerequisite 面向对象程序设计

课时及实验 24学时 1.5 学分 Lecture 12 学时 6次课 Lab 12 学时 6次课

Textbook 《UML 用户指南》 Grady Booch James Rumbaugh Ivar Jacobson 机械工业出版社 ISBN7-111-07564-1/TP

Grady Booch 因其在软件架构、软件工程和软件建模方面的杰出贡献而在国际上享有盛名。自 Rational 于1981年创建以来，他就一直担任 Rational 的首席科学家。于 2003 年 3 月荣获IBM fellow 的称号。 UML的最初开发人员之一，也是多个 Rational 产品的 最初开发人员之一。曾担任全世界许多复杂精深软件 项目的架构师和架构指导。 1977 年在美国空军学院获得科学学士学位 1979 在University of California at Santa Barbara 获得 电子工程科学 硕士学位 Grady 与他的妻子和猫生活在科罗拉多。他爱好阅读、旅游、唱歌和弹奏竖琴。

Dr. James Rumbaugh OMT 创始人 NY Schenectady GE R&D over 25 years 享誉全球的软件开发方法学家， IBM Fellow OMT 创始人 NY Schenectady GE R&D over 25 years 1994 年加入 Rational 软件公司 麻省理工学院的物理学 学士学位 加利福尼亚理工学院的天文学 硕士学位 麻省理工学院的计算机科学 博士学位

Dr. Ivar Jacobson 瑞典 Objectory AB 公司的创始人 Rational Business Engineering 部门的副总裁 OOSE创始人（面向用例） 两本影响深远的畅销书 《面向对象的软件工程―一种用例驱动方法》 《对象的优势―采用对象技术的业务过程再工 程》

Reference «UML与Rational Rose2002 从入门到精通» Wendy Bogge Michael Boggs 电子工业出版社 ISBN 7-5053-7731-0/TP

Reference «UML基础与Rose» 吴建，郑潮，汪杰 人民邮电出版社 ISBN 7-115-12711-6/TP

Reference «UML参考手册» James Rumbaugh Ivar Jacobson Grady Booch 机械工业出版社 ISBN 7- 111-08220-6/TP

工具

考核 出席 Lab 闭卷考试

本课程涉及的内容 Static Diagrams Dynamic Diagrams Class Diagrams Use-Case The UML emphasizes a graphical language for representing models, but provides little or no guidance on when and how to use these diagrams. This is an area where the RUP helps. It describes the kinds of project artifacts needed, including diagrams, and puts them in the context of an overall project plan. Static Diagrams Class Diagrams Use-Case Diagrams Object Diagrams Sequence Diagrams In building a visual model of a system, many different diagrams are needed to represent different views of the system. The UML provides a rich notation for visualizing our models. This includes the following key diagrams: Use-Case diagrams to illustrate user interactions with the system Class diagrams to illustrate logical structure Object diagrams to illustrate objects and links Component diagrams to illustrate physical structure of the software Deployment diagrams to show the mapping of software to hardware configurations Activity diagrams to illustrate flows of events Statechart diagrams to illustrate behavior Collaboration diagrams to illustrate behavior Sequence diagrams to illustrate behavior Notice that there is a single model (viewed through multiple diagrams) in which semantic consistency is maintained following the UML specifications. Collaboration Diagrams Component Diagrams Models Statechart Diagrams Deployment Diagrams Dynamic Diagrams Activity Diagrams

???????.......

石振莲 软件学院308 67396121 zshi@bjut.edu.cn 可视化建模与UML 石振莲 软件学院308 67396121 zshi@bjut.edu.cn

可视化建模与UML概论

Unit Objectives Describe the importance of visual modeling Define the principles of visual modeling What the Unified Modeling Language represents A Little bit Rational Rose

Why Modeling ？？？

Build a House for Dogs By one person Mini-Model Simple Process Simple Tools

Build a House By a team，more effective、more accurate time limitation Needs: Model Good defined process Powerful Tools

The Empire State Building Build a Building The Empire State Building

建造一个狗窝不需要太多的考虑，因为狗的需求是简单的，直接去建就可以满足他们的所有需求。 建造一座房子或者一座高层建筑就需要深思熟虑了。一个家庭或者客房的需求不那么不那么简单，因此即使为了满足客户最起码的需求，也不能直接去建造，而是必须建立以资额模型。不同的人员会从不同的角度宜不同的目的来看待问题，所以对于复杂的建筑物，你必须作平面图设计、立体图设计、暖气/冷气设计、电气设计、管道设计、甚至网络设计。没有任何一个模型能够充分地捕捉一个复杂建筑的所有方面。

回顾：软件发展的历史 软件 软件危机 软件工程

软件开发的历史就是软件规模不断变大的历史。最初几个人就可以编写的小程序，但软件规模很快就让他们变得无法应付。 系统日益壮大、异构、多平台、多语言、分布、安全、并行以及可信赖的复杂等问题。 间摸正是解决之道。 Watts S Hamphrey

软件开发问题的症状 对于最终用户的需要理解得不够精确 对需求的改变束手无策 程序块不兼容 软件不易维护或不易扩展 对项目严重缺陷的发现较晚 软件质量低劣 软件性能令人无法接受 开发组的人员按各自的方式进行开发，如果有人改变部分软件，将很难进行重组 一个不可靠的构造和发布过程

失败原因 特别的需求管理 模糊和不精确的交流 脆弱的构架 过度复杂 未检测出需求、设计和实现之间的不一致 测试的不足 对于项目状况的评估过于主观 未解决存在的风险 无法控制变化的产生和传播 自动测试不足

Trace Symptoms to Root Causes Animation note: mouse clicks Symptom highlighted Root causes highlighted Best practices highlighted Root Causes Best Practices Symptoms Needs not met Requirements churn Modules don’t fit Hard to maintain Late discovery Poor quality Poor performance Colliding developers Build-and-release Ambiguous communications Undetected inconsistencies Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Undetected inconsistencies Poor testing Subjective assessment Waterfall development Uncontrolled change Insufficient automation Modules don’t fit Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Model Visually (UML) Continuously Verify Quality Treat these root causes, and you’ll eliminate the symptoms. Eliminate the symptoms, and you’ll be in a much better position to develop quality software in a repeatable and predictable fashion. Best practices are a set of commercially proven approaches to software development, which when used in combination, strike at the root causes of software development problems. These are so-called “best practices,” not because you can precisely quantify their value, but rather because we observe their common use in the industry by successful organizations. The best practices are harvested from thousands of customers on thousands of projects and from industry experts.

Use Component Architectures Continuously Verify Quality 6 Best Practices 迭代地开发软件 管理需求 应用基于构件的架构 建立可视化的模型 不断地验证软件质量 控制软件的变更 Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change

总之—Why modeling? We build models of complex systems because we cannot comprehend such a system in its entirety We Build models to better understand the system you are developing 因为我们不能完整地理解一个复杂系统， 所以我们要对它建模 我们建模是为了能够更好地理解我们正在开发的系统

建模目的 帮助我们按照实际情况或按照我们所需要的样式对系统进行可视化 允许我们详细说明系统的结构或行为 模型给出一个指导我们构造系统的模版

Principles Of Modeling (建模原理) The model you create influences how the problem is attacked Every model may be expressed at different levels of precision The best models are connected to reality No single model is sufficient -- 选择要创建什么模型多如何动手解决问题和如何形成解决方案有着意义深远的影响 -- 每一种模型可以在不同的精度级别上表示 -- 最好的模型适于现实相联系的 --单个模型是不充分的。对每个重要的系统最好用一组几乎独立的模型去处理

OO Modeling 传统建模 OO建模

走向面向对象是必然的

用较稳定把不稳定包起来

???????.......

UML (Unified Modeling Language)

没有统一的数学符号，很难想象数学的发展。

没有五线谱，作曲家如何表达自己的灵感？？？

UML History UML2.0 1994年10月，Grady Booch 和Jim Rumbaugh 首先将Booch93 和OMT-2 统一起来，并于1995年10月发布第一个公开版本，称之为UM0.8（Unitide Method）。 1995年秋，OOSE 的创始人加盟到这一工作。 经过三人的努力，1996年6月和10月分别发布了两个新版本，UML0.9，UML0.91，并将UM 重新命名文UML。 UML的开发者倡议并成立了UML成员协会，以完善、加强和促进UML的定义工作。当时的成员有:DEC, HP, I-Logix、Itellicorp、IBM、ICONComputing、 MCI Systemhouse、Microsoft、Oracle、Rational Software、TI、Unisys。 UML 成员协会对UML1.0及UML1.1的定义和发布起了重要的促进作用。

Inputs to the UML

UML的统一

UML (Unified Modeling Language) Visualizing 可视化 Specifying 详述 Constructing 构造 Documenting 文档化 UML 是一种语言，提供了用于交流的词汇表和在词汇表中组合词汇的规则。词汇表和规则则注重于对系统进行概念上和物理上的描述。UML这样的建模语言正是用于软件蓝图的标准语言。贯穿于软件开发生命期，并能表达系统体系结构的各种不同视图。对软件密集型系统的制品进行：可视化、详述、构造、文档化 可视化： UML只是一组图形符号。确切地讲，UML表示法中的每一个符号都有明确语义。这样，一个开发者可以用UML绘制一个模型，而另外一个开发者可以无歧义的理解这个模型 详细描述的：详细描述意味着所建的模型是精确的、无歧义的和完整的。 构造性的：UML不是一种可视化的编程语言，但用UML描述的模型可以与各种编程语言直接相连。可以进行正向工程和逆向工程两种工程。 UML的文档化语言特性：一个健壮的软件组织除了生产可执行的代码之外，还要给出各种制品。通过这些制品的产出是度量和理解系统的关键。

UML 最适于的过程 Use-case driven 用况驱动的 Architecture-centric 以体系结构为中心 Iterative & incremental 迭代的和增量的 UML 在很大程度上是独立于过程，不依赖于任何特殊的软件开发生命周期。然而，为了从UML中得到最大的收益，应该考虑这样的过程。

A Use-Case Driven (用况驱动) Process 把用况作为一种基本制品，用于建立所要求的系统行为、验证和确认系统的体系结构、测试、项目组成员之间进行交流。 优点： 简洁、简单、易懂 同步不同模型的内容

Architecture-centric 以体系结构为中心 以系统的体系结构作为一种基本制品，用于在开发中队系统进行概念化、构造、管理、演化 可视化、详述、构造和文档化一个软件密集型系统，要求从几个角度去观察系统。各种人员—最终用户、分析人员、开发人员、系统集成人员、测试人员、技术资料作者和项目管理者，他们带着各自不同的日程，而且在项目的生命周期内各自在不同的时间、以不同的方式来开系统。系统能够体系结构或许是最重要的制品，他可以驾驭不同的观点，并在整个项目的生命周期内控制对系统的迭代和增量开发。 体系结构可以决策 * 软件系统的组织 * 对组成系统的结构元素及其接口的选择 * 元素间的协作所描述的那样的行为 * 将这些结构和行为元素组合到逐步增大的子系统 *指导这种组织的体系结构风格：静态和动态元素及其他们的接口、写作和组成 软件体系结构不尽关心结构和行为，而且还关心用法、功能、性能、弹性、复用、可理解性、经济技术约束及其折衷，以及审美的考虑。

Iterative & incremental 迭代和增量 风险驱动的，每个新发布都致力于处理和降低对项目成功影响力最为显著的风险。

R R R D D D C C C I I I T T T Time

UML 事物 关系 图 结构 事物 行为 事物 组织 事物 辅助 事物 关联 关系 依赖 关系 泛化 关系 实现 关系 静态 图 动态 图 交 互 状 态 机 包 注 释 用 例 图 类 图 对 象 图 构 件 图 实 施 图 用 例 类 接 口 协 作 活 动 类 组 件 节 点 顺 序 图 协 作 图 状 态 图 活 动 图

结构事物—类（Class） 一组具有相同属性、相同操作、相同关系和相同语义的对象的集合。 Class CRC card,(Class-Responsibility-Collaborator) Modeling Once basic usage scenarios have been developed for the system, it is time to identify candidate classes and indicate their responsibilities and collaborations. CRD modeling provide a simple means for identifying and organizing the classes that are relevant to system or product requirements. CRC模型实际上是一组表示类的标准的索引卡片集合。卡片被分成三个部分，在卡片的顶部为类的名字，在卡片的左边列出类的责任，在右边列出协作者。协作者是为某类提供完成责任所需要的信息的类。 CRC可以是虚拟的或索引卡片，其目的是开发一个有组织的类的表示法。

结构事物—接口（Interface） 描述一个类或构件的一个服务的操作集 Interface 换句话说，接口描述了类或构件的对外的、可见的动作。

结构事物—协作（Collaboration） 使对象和链共同工作以实现某种目标而进行的安排。 Collaboration 一组对象在给定的语境中，为了完成某个目标而交换信息，从而实现一种行为。

结构事物—用例（Use Case） 对一组动作序列的描述，系统执行这些动作将产生一个对特定的参与者有价值而且可观察的结果 Use Case 通过用例观察系统，能够将系统实现与系统目标分开，有助于让开发人员了解最重要的部分——满足用户需求和期望，而不会沉浸于实现细节。通过用例，客户可以看到系统实现的功能，可以确定系统范围在深入开展项目工作。 将项目分解成用例是面向对象过程，不同于传统的功能分解法。功能分解法关注如何分解成系统能处理的小块；用例关注用户对系统的需求。（如何寻找用例：检查客户提供的文档；询问项目保管人问题） 买票 Register for Class

结构事物—主动类（Active Class） 其对象至少拥有一个进程或线程，能够启动控制活动。 Active Class

结构事物—构件（Component） 系统中可替换的物理部分，封装了实现并提供一组接口的实现。 Component Java Bean winmine.exe 生成代码之前，每个文件应设相应组件。C++中，每个类映射两个组件，.cpp, .h. 构件是指系统中的一个物理实现片断，包括软件代码或相应成分。 配置组件：形成可执行文件的基础。 DLL，ActiveX， Java Bean 工作产品组件：数据库文件， 程序源代码 执行组件：最重可运行系统产生的运行结果 Windows 的扫雷游戏 (1) 当你点击扫雷图标开始游戏的时候，该图标所对应的winmine.exe就是配置组件； (2) 在扫雷开始后，会打开存储用户信息的数据文件，用于保持以前的最好成绩，这些都是工作产品组件。 (3) 游戏结束后，系统会把相应的成绩更新到用户数据文件，这是由可以算是执行文件。 .cpp .h

结构事物—节点（Node） 运行时的物理对象，代表一个计算资源，通常至少有存储空间和执行能力。一个构件集可以驻留在节点内，也可以从一个节点向另一个结点迁移。 Node

UML 事物 关系 图 结构 事物 行为 事物 组织 事物 辅助 事物 关联 关系 依赖 关系 泛化 关系 实现 关系 静态 图 动态 图 交 互 状 态 机 包 注 释 用 例 图 类 图 对 象 图 构 件 图 实 施 图 用 例 类 接 口 协 作 活 动 类 组 件 节 点 顺 序 图 协 作 图 状 态 图 活 动 图

行为事物—交互（Interaction） 共同完成一定任务的一组对象之间交换的消息组成 换句话说： 说明对象或其他实例是如何传递消息的 行为事物是UML模型的动态部分。他们是模型中的动词，描述了跨越时间和空间的行为。 交互是一组对象之间为完成某一任务（如实现一个操作）而进行的一系列消息交换的行为说明 Display

行为事物—状态机（State Machine） 描述了一个对象或一个交互在生命期内相应时间所经历的状态序列。 是对象的一个或多个状态的集合。 Waiting

UML 事物 关系 图 结构 事物 行为 事物 组织 事物 辅助 事物 关联 关系 依赖 关系 泛化 关系 实现 关系 静态 图 动态 图 交 互 状 态 机 包 注 释 用 例 图 类 图 对 象 图 构 件 图 实 施 图 用 例 类 接 口 协 作 活 动 类 组 件 节 点 顺 序 图 协 作 图 状 态 图 活 动 图

组织事物—包（Package） 把元素组织成组的机制。 结构事物、行为事物甚至其他组织事物都可以放进包内。 包

UML 事物 关系 图 结构 事物 行为 事物 组织 事物 辅助 事物 关联 关系 依赖 关系 泛化 关系 实现 关系 静态 图 动态 图 交 互 状 态 机 包 注 释 用 例 图 类 图 对 象 图 构 件 图 实 施 图 用 例 类 接 口 协 作 活 动 类 组 件 节 点 顺 序 图 协 作 图 状 态 图 活 动 图

辅助事物—注释（note） UML模型的解释部分，用来描述、说明和标注模型的任何元素。 注视

UML 事物 关系 图 结构 事物 行为 事物 组织 事物 辅助 事物 依赖 关系 关联 关系 泛化 关系 实现 关系 静态 图 动态 图 交 互 状 态 机 包 注 释 用 例 图 类 图 对 象 图 构 件 图 实 施 图 用 例 类 接 口 协 作 活 动 类 组 件 节 点 顺 序 图 协 作 图 状 态 图 活 动 图

如果你正在建造一所房子，像墙、门、窗户、柜橱和照明灯具这样的事物将形成部分词汇。然而这些事物都不是单独存在的。墙要与别的墙相连接，门窗要安在墙上，形成供人们出入和采光的开口。橱柜和照明灯具安在墙上和天花板上。把墙、门、窗户、橱柜和照明灯具组合在一起，就形成了向房间这样较高层次的事物。 在这些事物中，不仅能发现结构关系，而且也能发现其他种类的关系。例如，房子肯定有窗户，但窗户的种类可能有很多种，无论他们多么不同，他们都具有一些基本的窗户要素：每个窗户都是墙上的一个开口，被设计用于采光和通气，有是还能过人。 到目前为止，我们已经了解了要建软件大厦的基本要素（类，接口，协作，用例，构件，节点），接下来我们就来讨论如何把这些分离的元素联系起来，建成建成软件大厦。在UML中，事物之间相互联系的方式，无论是逻辑上的还是物理上的，都被建模为关系。 UML关系。

UML 事物 关系 图 结构 事物 行为 事物 组织 事物 辅助 事物 依赖 关系 关联 关系 泛化 关系 实现 关系 静态 图 动态 图 交 互 状 态 机 包 注 释 用 例 图 类 图 对 象 图 构 件 图 实 施 图 用 例 类 接 口 协 作 活 动 类 组 件 节 点 时 序 图 协 作 图 状 态 图 活 动 图

UML—依赖关系（Dependency） 两个元素之间的一种关系，其中一个元素的变化将影响另一个元素。 依赖性关系显示一个类引用另一个类。因此，引用类规范改变可能影响使用类。 两个类有依赖关系时，并不对关系的类增加属性，这是关联与依赖性关系的一个不同。 关联可以是双向的，而依赖性只能是单向的。这是关联与依赖性的第二个差别。 含义是：Flight要设法知道Customer 的存在，箭头方向表示Flight依赖于Customer。换句话说：Flight向Customer发消息。 如果是正常关联，则Flight应有Customer属性，要向Customer发消息，Flight只要查找自己的Customer属性。 但在依赖性关系中，Flight没有Customer属性，因此要用其他方法查找Customer。有三种方法： （1）如果Customer是全局的，则Flight知道他存在。 （2）如果Customer实例化为Flight操作中的本地变量，则Flight知道它存在。 （3）如果Customer作为参数传递到Flight操作中，则Flight知道它的存在。

依赖关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的事物，反之不成立。在你想显示一个事物使用另一个事物时使用依赖关系。                                                                                                            依赖关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的事物，反之不成立。在你想显示一个事物使用另一个事物时使用依赖关系。 通常情况下，依赖关系体现在某个类的方法使用另一个类作为参数。在UML中你可以在其它的事物之间使用依赖关系，特别是包和节点之间。

Public class Flight { private int FlightNumber; private date DepartureDate; private string DepartureCity; Private string ArrivalCity; private long RegFare; private long DiscontFare; private long FirstClassFare; public Flight } …… Public class Customer { private string FirstName; private string LastName; private string Address; Private string City; private string State; private long Zip; private long Phone; public customer } ……

UML—关联关系（Association） 如果几个类元的实例之间有联系，那么这几个类元之间的语义关系即关联 ClassA ClassB 关联既可以是单向的，也可以是双向的。

双向关联

Public Class Customer { public Flight the Flight; Public Customer() } Public class Flight { public Customer the Customer; public Flight() }

单向关联

Public class Flight { public Class the Customer; public Flight() } Public Class Customer { Public Customer() }

UML—泛化关系（Generalization） 特殊和一般关系 is a kind of… …

UML—实现关系(Realization) 两个元素之间的关系，在这个关系中，其中一个元素的外部行为规格说明部分影响另外一个元素的实现部分。 PopUpMenu ChoiceBlock 买票

UML 事物 关系 图 结构 事物 行为 事物 组织 事物 辅助 事物 依赖 关系 关联 关系 泛化 关系 实现 关系 静态 图 动态 图 交 互 状 态 机 包 注 释 用 例 图 类 图 对 象 图 构 件 图 实 施 图 用 例 类 接 口 协 作 活 动 类 组 件 节 点 顺 序 图 协 作 图 状 态 图 活 动 图

UML——图 Static Diagrams Dynamic Diagrams 结构 行为 Use-Case Diagrams Class The UML emphasizes a graphical language for representing models, but provides little or no guidance on when and how to use these diagrams. This is an area where the RUP helps. It describes the kinds of project artifacts needed, including diagrams, and puts them in the context of an overall project plan. Static Diagrams 结构 Use-Case Diagrams Class Diagrams Sequence Diagrams Object Diagrams In building a visual model of a system, many different diagrams are needed to represent different views of the system. The UML provides a rich notation for visualizing our models. This includes the following key diagrams: Use-Case diagrams to illustrate user interactions with the system Class diagrams to illustrate logical structure Object diagrams to illustrate objects and links Component diagrams to illustrate physical structure of the software Deployment diagrams to show the mapping of software to hardware configurations Activity diagrams to illustrate flows of events Statechart diagrams to illustrate behavior Collaboration diagrams to illustrate behavior Sequence diagrams to illustrate behavior Notice that there is a single model (viewed through multiple diagrams) in which semantic consistency is maintained following the UML specifications. Collaboration Diagrams Component Diagrams Models 行为 Statechart Diagrams Deployment Diagrams Activity Diagrams Dynamic Diagrams

Use Case Diagram（用例图） 展现一组用例、参与者及其他们之间的关系。 可以用用例图描述系统的静态使用情况。在对系统行为组织和建模方面，用例图是相当重要的。

Class Diagram（类图） 展现一组对象、接口、协作和它们之间的关系。 系统可由多个类图，单个类图仅表达了系统的一个方面。一般在高层给出类的职责，在低层给出泪的属性与操作。

Object Diagram（对象图） 显示某时刻对象和对象之间的关系。

Component Diagram（构件图） 软件构件之间的依赖关系 又称组件图，展现了一组组建之间的组织和依赖，用于对源代码、可执行的发布、物理数据库和可调整的系统建模。

Deployment Diagram（实施图） 展现对运行时处理节点以及其中组件的配置。 相互之间是关联关系

Sequence Diagram（顺序图） 强调消息的时间顺序的交互图。 该图反映了用户与ATM的交互过程：用户把卡插入ATM中，ATM向用户发出需要密码指令，用户再把密码提供给ATM……

Collaboration Diagram（协作图） 强调收发消息的对象的组织结构。 : Customer : ATM U.S Chinese 1: Inquiry 2: Inquiry 3: Return 4: Inquiry 5: Return 6: Return 顺序图和协作图都是交互图，展现了一种交互，它们是同构的，可以互相转换。

Statechart Diagram（状态图） 展示了一个特定对象的所有可能状态以及由于各种事件的发生而引起的状态间的转移。 Insert Card Ask PW Enter PW Waiting... Start 一个状态图描述了一个状态机，用状态图说明系统的动态视图。有状态、转换、时间和活动组成。状态图对于接口、类或协作的次年改为建模尤为重要，可用它描述用例实例的生命周期。 Verify PW Take Card Complish Valid End Others

Activity Diagram（活动图） 活动图显示了系统内从一个活动到另一个活动的流程。 Insert Card Enter PW Verify PW Other Take Card 专注于系统的动态视图，对系统的功能建模特别重要，并强调对象间的控制流程。 活动图一活动作为节点，从开始状态起步，进入插入卡活动，然后输入密码，系统验证密码，并进行其他工作，最后用户取卡，活动结束。

Target System Use-Case Diagram Statechart Diagram Class Diagram The point to be made is that the UML is the language we use to visually model. Since it is a widely adopted standard, it facilitates the understanding and communication of the visual models we create. Activity diagrams are not shown on the slide. Activity diagrams can be used to model workflows in business process engineering. Statechart Diagram Class Diagram Use Case 1 GrpFile read( ) open( ) create( ) fillFile( ) rep Repository name : char * = 0 readDoc( ) readFile( ) (from Persistence) FileMgr fetchDoc( ) sortByName( ) DocumentList add( ) delete( ) Document name : int docid : int numField : int get( ) close( ) sortFileList( ) fillDocument( ) fList 1 FileList File read() fill the code.. Actor A Actor B Use Case 2 Use Case 3 Deployment Diagram Collaboration Diagram 9: sortByName ( ) Document FileManager GraphicFile File Repository DocumentList FileList mainWnd : MainWnd Window95 Windows95 1: Doc view request ( ) Windows95 L 2: fetchDoc( ) 4: create ( ) gFile : GrpFile ¹®¼­°ü¸® Ŭ¶óÀ̾ðÆ®.EXE ¹®¼­°ü¸® ¾ÖÇø´ 8: fillFile ( ) Windows user : Clerk NT Solaris fileMgr : FileMgr ¹®¼­°ü¸® ¿£Áø.EXE 6: fillDocument ( ) 3: create ( ) Visual modeling with the UML makes a system’s architecture tangible, permitting you to assess it in multiple dimensions. How portable is it? Can it exploit expected advances in parallel processing? How might you modify it to support a family of systems? The importance of architectural resilience and quality has already been discussed. The UML enables us to evaluate these key characteristics during early iterations—at a point when design defects can be corrected before threatening project success. Advances in forward and reverse engineering techniques permit any changes to an application’s model to be automatically reflected in its source code, and changes to its source code to be automatically reflected in its model. This is critical when using an iterative process, where you expect such changes with each iteration. Windows NT ÀÀ¿ë¼­¹ö.EXE Alpha UNIX 5: readDoc ( ) 7: readFile ( ) Mainframe IBM repository : Repository document : Document µ¥ÀÌŸº£À̽º¼­¹ö Component Diagram mainWnd fileMgr : FileMgr document : user Document gFile repository Target System ƯÁ¤¹®¼­¿¡ ´ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äûÇÑ´Ù. 1: Doc view request ( ) 2: fetchDoc( ) 3: create ( ) 4: create ( ) 5: readDoc ( ) È­ÀÏ°ü¸®ÀÚ´Â Àоî¿Â °´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù. ¹®¼­ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼­ 6: fillDocument ( ) Forward and Reverse Engineering 7: readFile ( ) 8: fillFile ( ) °´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î È­¸é °´Ã¼´Â ÀоîµéÀÎ Á¤·ÄÀ» ½ÃÄÑ È­¸é¿¡ º¸¿©ÁØ´Ù. 9: sortByName ( ) Sequence Diagram

Architecture Views 设计视图 实现视图 进程视图 实施视图 Design View Implementation View The 4+1 model is introduced here and because it is important for the students to see how the views fit together up front, in order to set context. Discuss the 4+1 views at a high level. These are covered in detail in RUP. Emphasize that the architectural views are the architecturally-significant subsets of system models. Not all systems require all views (e.g., single processor: drop deployment view; single process: drop process view; small program: drop implementation view, etc.). A project may document all of these views or additional views. The number of views is dependent on the system you’re building. These views and their representation in UML are discussed in the Artifacts module. Note: More information than the views is required to capture the software architecture. This information is captured in the Software Architecture Document (SAD). Design View Analysts/Designers Structure 设计视图 Implementation View Programmers Software management 实现视图 Use-Case View End-user Functionality 用例视图 Many different parties are interested in the architecture (such as the system analyst, the designers, the end users, and so on). To allow these parties or stakeholders to communicate, discuss, and reason about architecture, you need to have an architectural representation they understand. Because different stakeholders have different concerns and because architecture is quite complex, multiple views are required to represent architecture adequately. An architectural view is a simplified description (an abstraction) of a system from a particular perspective or vantage point, covering particular concerns, and omitting entities that are not relevant to this perspective. While many views of architecture can be useful, RUP identifies 4+1 views as a standard set: * The Design view addresses the conceptual structure of the system. It is an abstraction of the design model, identifying major design packages, subsystems, and classes. 包含了类、接口和协作，它们形成了问题及其对问题解决方案的术语词汇。这种视图主要支持系统的功能需求，即系统提供给 用户的服务。静态视图：类图、对象图； * The implementation view describes the organization of static software modules in the development environment, in terms of packaging, layering, and configuration management. 包含了用于装配与发布物理系统的构件和文件。这种视图主要针对系统发布的配置管理，由一些独立的构件和文件组成。 静态视图：构件图 * The deployment view shows how the various executables and other run-time components are mapped onto the underlying platforms or computing nodes. 包含了形成系统硬件拓扑结构的节点。主要描述组成物理系统的部件的分布、交付和安装。 静态图：实施图； 动态图：交互图、状态图、活动图 * The process view addresses the concurrent aspects of the system at run-time: tasks, threads or processes, and their interactions. 包含了形成系统并发与同步机制的线城和进程。主要针对性能、可伸缩性、系统的吞吐量。注重于描述进程和线程的主动 类。 静态图：类图，对象图 动态图：交互图、状态图、活动图。 * The use-case view contains a few key scenarios or use cases that are used to drive and validate the architecture. It is the “heart” of the other views because it specifies WHAT the system should do. 由专门描述可被最终用户、分析人员和测试人员看到的系统行为的用例组成，用例视图实际上没有描述软件系统的组织，而是描述了形成系统体系结构的动力。 静态图：用例图 动态图：交互图、状态图和活动图。 UML中，可以将软件密集型系统的所有抽象组织成一些模型，每个模型代表正在开发的系统的相对独立而又重要的方面。然后用图来可视化这些抽象的有趣集合。 最好用5个互连的视图来描述软件密集型系统的体系结构。每一个视图是在一个特定的方面对系统的组织和结构进行的投影。这五种视图中的每一种视图头可单独使用，使不同的人员能专注于他们最关心的体系结构的问题。这五种视图也可以相互作用。(See Page 22) Process View Performance Scalability Throughput System integrators 进程视图 Deployment View System topology Delivery, installation communication System engineering 实施视图 Logic Model Physic Model

Diagram Toolbar Browser Diagram Window Docu. Window Log Window We will now look at the views and diagrams in the Rational Rose tool and become familiar with its interface features and functions Docu. Window Log Window

UML 事物 关系 图 结构 事物 行为 事物 组织 事物 辅助 事物 依赖 关系 关联 关系 泛化 关系 实现 关系 静态 图 动态 图 交 互 状 态 机 包 注 释 用 例 图 类 图 对 象 图 构 件 图 实 施 图 用 例 类 接 口 协 作 活 动 类 组 件 节 点 顺 序 图 协 作 图 状 态 图 活 动 图

Unit Review Why modeling Modeling Principles UML Rational Rose