首席软件专家 张恂 博讯科技（上海）有限公司 浩方科技集团 2000.11 OO方法、RUP与UML建模 首席软件专家 张恂 博讯科技（上海）有限公司 浩方科技集团 2000.11

主要内容 一、OOAD与UML表示法 二、RUP建模过程与步骤 三、讨论

一、OOAD与UML表示法

OO原则 Abstraction（抽象） Encapsulation（封装） Modularity（模块化） Hierarchy（分层）

OO三要素 封装 继承 多态

OO基本概念 对象 类 属性 操作（方法） 接口（多态）* 构件* 关系 包 子系统*

接口与多态 Polymorphism: The ability to hide many different implementations behind a single interface. Interfaces formalize polymorphism, support “plug-and-play” architectures.

接口与多态

Component A non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture. source code component, run time components, executable component

Subsystem A combination of a package (can contain other model elements) and a class (has behavior) Realizes one or more interfaces which define its behavior.

OOAD是主流技术 OOAD大部分情况下比结构化设计好： 结构化设计是过时的东西，它强调软件的结构按照功能来组织，一旦功能改变，软件的结构就会不稳定。 而OO设计把数据流和功能统一起来，IT行业绝大部分（70-80%）的软件设计（包括数据库设计）可以采用OO方法，目前国外流行的趋势也是这样，剩下的少部分有特定需求的可能还会用传统方法。 另外在电信界，用有限自动状态机的SDL方法仍占绝大数，但现在UML和SDL出现了融合的趋势。

Object Oriented Analysis 用面向对象方法分析问题域，建立基于对象、消息的业务模型，形成对客观世界和业务本身的正确认识。 生成业务对象的动、静态模型和抽象类。

Object Oriented Design 针对OOA给出的问题域模型，用面向对象方法设计出软件基础架构（概要设计）和完整的类结构（详细设计），以实现业务功能。 生成对象类的动、静态模型（解决域）。

Analysis vs. Design Analysis Design Focus on understanding the problem Idealized design Behavior System Structure Functional requirements A small model Design Focus on understanding the solution Operations and Attributes Performance Close to real code Object lifecycles Non-functional requirements A large model

“4+1”视图 Use Case View (End-user: Functionality) Logical View (Analysts/Designers: Structure) Process View (System integrators: Performance, Scalability, Throughput) Implementation View (Programmers:Software management) Deployment View (System engineering: System Topology, Delivery, installation, communication)

UML图示 Use Case Diagram Sequence Diagram Class Diagram Collaboration Digram State Diagram Activity Diagram Component Diagram Deployment Diagram

Actor - 用户 “An Actor defines a coherent set of roles that users of use cases play when interacting with use cases. An actor has one role for each use case with which it communicates.” 角色的集合，可以是人或外部系统。 定义了“系统边界”。

Use Case - 用例 The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system. A use case is a coherent unit of functionality provided by a system, a subsystem, or a class as manifested by sequences of messages exchanged among the system and one or more outside interactors (called actors) together with actions performed by the system.

Business Use Case/Actor

Business - System 例子

课程登记系统

Use Case依赖关系 • Association – The participation of an actor in a use case, i.e. instances of the actor and instances of the use case communicate with each other. This is the only relationship between actors and use cases. • Extend – An extend relationship from use case A to use case B indicates that an instance of use case B may be extended (subject to specific conditions specified in the extension) by the behavior specified by A. The behavior is inserted at the location defined by the extension point in B which is referenced by the extend relationship.

Use Case依赖关系 • Generalization – A generalization from use case A to use case B indicates that A is a specialization of B. • Include – An include relationship from use case A to use case B indicates that an instance of the use case A will also include the behavior as specified by B. The behavior is included at the location which defined in A.

产品定购管理

Actor Generalization

Sequence Diagram A diagram that shows object interactions arranged in time sequence. In particular, it shows the objects participating in the interaction and the sequence of messages exchanged. Unlike a collaboration diagram, a sequence diagram includes time sequences but does not include object relationships. A sequence diagram can exist in a generic form (describes all possible scenarios) and in an instance form (describes one actual scenario). Sequence diagrams and collaboration diagrams express similar information, but show it in different ways.

序列图元素

Use Case描述 简述： This use case allows a Student to register for course offering in the current semester. The Student can also update or delete course selections if changes are made within the add/drop period at the beginning of the semester. The Course Catalog System provides a list of all the course offerings for the current semester.

事件流 Basic Flow: This use case start when a Student wishes to register for course offerings, or to change his/her existing course schedule. 1. The system requests that the Student specify the function he/she would like to perform (either Create a Schedule, Update a Schedule, or Delete a Schedule). 2. Once the Student provides the requested information, one of the subflows is executed. If the Registrar selected “Create a Schedule”, the Create a Schedule subflow is executed. (Update a Schedule, Delete a Schedule)

Create a Schedule 1. The system retrieves a list of available course offerings from the Course Catalog System and displays the list to the Student. 2. The Student selects 4 primary course offerings and 2 alternate course offerings from the list of available offerings. 3. Once the student has made his/her selections, the system creates a schedule for the Student containing the selected course offerings. 4. The Submit Schedule subflow is executed.

类的划分 边界类 控制类 实体类

选课

理解Use Case和Actor 1）Use Case绝不是锦上添花的东西，一方面它可以促进与用户沟通，理解正确的需求，另一方面它可以划分系统与外部实体的界限，是系统设计的起点，而最终应该落实到类和实现代码上。 2）Use Case View与Logical View应该由明确的相关性。UML中从Use Case到类包的关联可以用依赖（或实现）关系描述。 3）Actor不是指人，而是指代表某一种特定功能的角色，因此同一个人可能对应很多个Actor。Actor是虚拟的概念，可以指外部系统和设备。 4）Use Case是对系统行为的动态描述，它是OO设计的起点，是类、对象、操作的来源，而通过逻辑视图的设计，可以获得软件的静态结构。

Class Diagram A diagram that shows a collection of declarative (static) model elements, such as classes, types, and their contents and relationships.

Class

Export Control Public The element is visible outside of the enclosing package and you can import it to other portions of your model. Operations are accessible to all clients. Protected The element is accessible only to nested classes, friends, or to the class itself. Private The element is accessible only to nested classes, friends, or to the class itself. Implementation The element is visible only in the package in which it is defined. An operation is part of the implementation of the class.

类的并发性 Sequential (default) - The semantics of the class are guaranteed only in the presence of a single thread of control. Only one thread of control can be executing in the method at any one time. Guarded - The semantics of the class are guaranteed in the presence of multiple threads of control. A guarded class requires collaboration among client threads to achieve mutual exclusion. Active - The class has its own thread of control. Synchronous - The semantics of the class are guaranteed in the presence of multiple threads of control; mutual exclusion is supplied by the class.

参数化和实例化类 Parameterized/Instantiated Class C++ Template

Utility Class

关系 Association Dependency Realization Generalization (inheritance) Aggregation Composition Dependency Realization Generalization (inheritance)

Realization

聚合关系 Aggregation: A special form of association that models a whole-part relationship between an aggregate (the whole) and its parts.

合成关系 Composition: A form of aggregation with strong ownership and coincident liftimes. The parts cannot survive the whole/aggregate.

Association 关联类

Multiplicity 关系的多重性 Exactly One: 1 Zero or more: 0..n One or more: 1..n Zero or one: 0..1 Specified range: 2..4 Multiple, disjoint ranges: 2,4..6

Generalization inheritance

Dependency A dependency indicates a semantic relationship between two (or more) model elements. It relates the model elements themselves and does not require a set of instances for its meaning. It indicates a situation in which a change to the target element may require a change to the source element in the dependency.

依赖关系 bind – Binding: A binding of template parameters to actual values to create a nonparameterized element. trace – Trace: A historical connection between two elements that represent the same concept at different levels of meaning. refine – Refinement: A historical or derivation connection between two elements with a mapping (not necessarily complete) between them.

依赖关系 use – Usage: A situation in which one element requires the presence of another element for its correct implementation or functioning. May be stereotyped further to indicate the exact nature of the dependency, such as calling an operation of another class, granting permission for access, instantiating an object of another class, etc. Maps into a Usage. If the keyword is one of the stereotypes of Usage (call, create, instantiate, send) then it maps into a Usage with the given stereotype.

依赖关系 derive – Derivation A computable relationship between one element and another (one more than one of each). access - The granting of permission for one package to reference the public elements owned by another package (subject to appropriate visibility). Maps into a Permission with the stereotype access. import - The granting of permission for one package to reference the public elements of another package, together with adding the names of the public elements of the supplier package to the client package. Maps into a Permission with the stereotype import.

四种UML依赖关系异同 绑定关系位于模板（如C++模板）和用其生成的模型元素之间，该元素完全是模板的实例化，为添加任何新的东西。 可溯关系是两个元素或元素集合之间的概念连接，用于描述位于不同语义层或多种视点下的同一个概念。这些元素间并没有任何特定的映射关系，关系的方向可被忽略。通常用于跟踪需求，或帮助建模者跟踪多个模型的变化。 使用关系表示一个元素为了实现或完成其全部的功能需要其它元素或元素集合的配合，例如类与类之间的多种方法调用关系。 细化关系是不同语义层（如分析和设计）之间模型元素的依赖关系，表示客户可由供应者导出。这一导出关系不一定非要用算法来描述，可以完全人为决定，因此细化关系可描述的语义范围较广，包括：模型的逐步细化、优化、变换、模板、模型合成、框架组成等等。 绑定和使用关系只能用于同一模型中元素的连接，而可溯和细化关系可用于连接多个模型的元素。

Interface

Collaboration Diagram A diagram that shows interactions organized around the structure of a model, using either classifiers and associations or instances and links. Unlike a sequence diagram, a collaboration diagram shows the relationships among the instances. Sequence diagrams and collaboration diagrams express similar information, but show it in different ways.

协作图元素 Object Class instance

完成课程登记

State Diagram State: A condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event.

选课

History The history icon provides a mechanism to return to the most recently visited state or activity when transitioning directly to a state or activity with substates. History applies to the given level in which it appears.

Activity Diagram An activity is an ongoing non-atomic (in other words, interruptible) execution within a state machine. An activity graph is a state machine in which most or all of the states are action states or activity states, and in which most or all of the transitions are triggered by completion of activity in the source states. An activity graph emphasizes the sequential and concurrent steps of a computational procedure or a workflow.

用途 描述业务模型（Use Case分析） 描述类动态模型（类设计） An activity graph is a variation of a state machine in which the states represent the performance of actions or subactivities and the transitions are triggered by the completion of the actions or subactivities. It represents a state machine of a procedure itself. 描述业务模型（Use Case分析） 描述类动态模型（类设计）

活动图与状态图比较 An activity diagram is a special case of a state diagram in which all (or at least most) of the states are action or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or subactivities in the source states. The entire activity diagram is attached (through the model) to a class, such as a use case, or to a package, or to the implementation of an operation. The purpose of this diagram is to focus on flows driven by internal processing (as opposed to external events). Use activity diagrams in situations where all or most of the events represent the completion of internally-generated actions (that is, procedural flow of control). Use ordinary state diagrams in situations where asynchronous events occur.

Action state An action state is a shorthand for a state with an entry action and at least one outgoing transition involving the implicit event of completing the entry action (there may be several such transitions if they have guard conditions). Action states should not have internal transitions or outgoing transitions based on explicit events, use normal states for this situation. The normal use of an action state is to model a step in the execution of an algorithm (a procedure) or a workflow process.

Activity state A subactivity state invokes an activity graph. When a subactivity state is entered, the activity graph “nested” in it is executed as any activity graph would be. The subactivity state is not exited until the final state of the nested graph is reached, or when trigger events occur on transitions coming out of the subactivity state. Since states in activity graphs do not normally have trigger events, subactivity states are normally exited when their nested graph is finished. A single activity graph may be invoked by many subactivity states.

Action-Object Flow Actions operate by and on objects. These objects either have primary responsibility for initiating an action, or are used or determined by the action. Actions usually specify calls sent between the object owning the activity graph, which initiates actions, and the objects that are the targets of the actions.

举例 1）选课程计划 2）户籍管理 3）喝咖啡

Component Diagram A physical, replaceable part of a system that packages implementation and conforms to and provides the realization of a set of interfaces. A component represents a physical piece of implementation of a system, including software code (source, binary or executable) or equivalents such as scripts or command files.

component a software module (source code, binary code, executable, DLL, etc.) with a well-defined interface.

Componet stereotypes Main programs，主程序 Packages，构件包 Subprograms，子程序 Tasks，独立线程 EXE，可执行文件 DLL，动态连接库

任务 独立线程。

子程序 不含类声明。

动态链接库

主程序

构件包 子系统

构件依赖关系 软件模块的编译和运行时关系。 client component can inherit from, contain instances of, use, and otherwise depend on classes that are exported from the supplier component. You can draw a dependency relationship from a component to an interface of another component, which means that the client component uses the operations of the other component. You can also draw a realize relationship from a component to an interface of another component, which means that the client component provides the operations of the other component.

Deployment Diagram A diagram that shows the configuration of run-time processing nodes and the components, processes, and objects that live on them. Components represent run-time manifestations of code units. 处理机 设备

处理机 Characteristics Processes 进程优先级 硬件的物理描述。the connection type and bandwidth, the manufacturer, model, memory, and disks of a machine, or the kind and size of a device. Processes Processes denote the root of a main program from a component diagram or the name of an active object from a collaboration diagram. 进程优先级

处理机 Scheduling，进程调度方式 preemptive（缺省），抢占式 non-preemptive，非抢占式 cyclic，循环式 executive，算法控制 manual，外部控制

Device 无计算能力的外部设备，如modem、终端。 the connection type and bandwidth, the manufacturer, model, memory, and disks of a machine, or the kind and size of a device

Connection 连接，两个实体间的硬件耦合，通信通道。 直接连接，如RS-232。 间接连接，如卫星。

二、RUP建模过程与步骤

系统分析、设计工作流

Use Case分析步骤 Supplement the Use-Case Description For each use-case realization Find Classes from Use-Case Behavior Distribute Use-Case Behavior to Classes For each resulting analysis class Describe Responsibilities Describe Attributes and Associations Qualify Analysis Mechanisms Unify Analysis Classes Checkpoints [举例]

Use Case View Business Object Model（可选） describing the business Use Case Model for the system a model of the behavior of a system which supports the business processes.

Use Case Model The Use-Case Model is traceable to (and derives from) the Business Model. The system (as described in the Use Case Model) provides behavior that supports the business.

Use Case package Use Case package All Use Cases in the system are contained in this package. This is done strictly as a way to organize the model and make it easier to understand. Use Cases are often documented in a separate text file, use the Rational Unified Process template or use the use case template in Rational Requsite Pro. The "Use Case Realizations" that correspond to these use cases are created in the Design Model..

Use Case package Included Use Cases package contains "common" use cases which are textually included in one or more other use cases. They are organized in this package to promote greater reuse. Architecturally Significant Use Cases diagram contains all architecturally significant use cases. <Annotations may be added to the diagram to explain why particular use cases are architecturally significant.>

Actor Package Actor package All Actors in the system are contained in this package. This is both as a way to organize the model, making it easier to understand, and to provide a way to manage the actors in a single configuration item.

Logical View Analysis Model (optional) Business Object Model contains a set of Analysis Classes, which describe an abstract realization of the use cases of the system; evolve into associated design elements which are modeled in the Design Model. Business Object Model Design Model

Business Object Model contains a set of interacting workers and business entity (domain) classes which collaborate to enact the business processes. In some cases, only the business entity classes are documented. The business entity classes as a whole are sometimes referred to as a 'domain model'. The business modeling workflow in Rational Unified Process produces two models: the business use-case model, and the business object model. Both show the business processes, but different aspects of them. In the business use-case model each business use case represents a business process, described (text and/or activity diagrams) from an "external" view point without worrying about who does what to whom inside of the organization. In the business object model, you include realizations of each business use case to show how workers and entities collaborate to perform the process. You do that using class diagrams, activity diagrams with swimlanes, collaboration diagrams, and/or interaction diagrams.

Design Model is adapted to model the real implementation environment, and serves as an abstraction of the source code. It is a "blueprint" of how the source code is structured and written. The design model is a hierarchy of packages (design subsystems and design-service packages), with "leaves" that are classes. Subsystems are a design "view" of the components that are defined in the Implementation Model. The design model hierarchy consists of layers. Classes represent abstractions of classes in the system's implementation. They define the objects, which in turn are abstractions of the objects in the system's implementation. The use cases are realized by the objects, and this is represented by use-case realizations in the Design Model. Each use-case realization has a realize dependency to a use case in the Use-Case Model.

Design Model Layer Process View Use Case Realizations An architectural view that describes the concurrent aspect of the system: tasks (processes) and their interactions. Use Case Realizations Architecturally Significant Model Elements Architecture Overview - Package, Subsystem Layering

Layer The design model is normally organized in layers. The number of layers is not fixed, but varies from situation to situation. During architectural analysis, focus is normally on the two high-level layers, that is, the application and business-specific layers; this is what is meant by the "high-level organization of subsystems." The other lower-level layers are in focus during architectural design, refer to the activity Architectural Design for more information.

Layer - package A package should be used in cases where a set of classes and/or other packages need to be grouped together for model organization purposes. Though the contents of the package can have public visibility, which makes them visible to model elements outside the containing package, packages are primarily just grouping mechanisms. If a set of classes is to be encapsulated and can be hidden behind a well-defined interface, a subsystem is a more appropriate container.

Layer - subsystem A subsystem should be used in cases where a set of classes and/or other packages need to be encapsulated within a container and hidden behind a set of well-defined interfaces. By convention, none of the contents of subsystem are visible except the interfaces of the subsystem. This allows subsystems to be easily replaced, and the implementations changed, provided the interfaces remain unchanged. It offers a degree of encapsulation greater than that of the package. If a set of classes is merely to be grouped together, but public visibility of classes is still desirable, a package is a more appropriate container.

Subsystem设计步骤 Distribute Subsystem behavior to Subsystem Elements Document Subsystem Elements Describe Subsystem Dependencies Checkpoints

Class设计步骤 Create Initial Design Classes Identify Persistent Classes Define Operations Define Class Visibility Define Methods Define States Define Attributes Define Dependencies Define Associations Define Generalizations Resolve Use Case Collisions Handle Non-Functional Requirements in General Checkpoints

Process View Process view diagram - illustrates the composition of processes and threads, and the mapping of classes onto those processes and threads.

Use Case设计步骤 Describe Interactions Between Design Objects Simplify Interaction Diagrams Using Subsystems (optional) Describe Persistence-Related Description Refine the Flow of Events Description Unify Classes and Subsystems Checkpoints

Use Case Realizations package In this Package we will describe "Use Case Realizations" as stereotyped use cases. A use-case realization describes how a particular use case is realized within the design model, in terms of collaborating objects. A realize dependency is used between the "Use Case Realization" and the "Use Case" in the use-case model that is realized.

Use Case Realization Participating classes diagram realize dependicies Sequence Diagram basic type, other flow type

Component View Implementation Model is a collection of components, and the implementation subsystems that contain them. An architectural view that describes one or several system configurations; the mapping of software components (tasks, modules) to the computing nodes in these configurations. Defines executables, dlls, files, subsystems, compilation order etc. It is recommended that, in most cases, the mapping should be 1:1 between design and implementation, that is, for each package in design there is one subsystem in the implementation model.

Deployment View Defines the typical physical network configurations, including those typically used by end users, as well as special configurations used for development and test. Allocate processes to the various nodes. Allocation takes into account the capacity of the nodes (in terms of both memory and processing), bandwidth of the communication medium (bus, LANs, WANs), and the availability of the hardware and communication links, rerouting, and so on.

三、讨论

3.RUP的方法是迭代式的，是不是可以理解为软件开发时先做一个简单的，实现基本功能的软件，然后再不断的改进，但是以前的开发过程中，有些情况应该首先将界面设计好，然后在编写业务代码的同时，同步进行使用手册、产品演示等工作，如果采用RUP应该如何协调？ Risk-driven Milestone

4.我觉得完全按照Rose的各种框图设计太繁琐了，能不能推荐一种简化的方案？ 应动静结合，不能随意简化，否则对系统的认识不完整，最终以说清楚为准。 可参考Rose RUP Framework。

5.Rose的中文化问题,哪些对象的命名可用中文?如Sequence图中的Message命名是否不能用中文? 业务模型、抽象类，不影响代码生成的图形元素均可以。

6.Sequence图与Class图是否是同时生成并交互修改? 1）严格地说，一上来就画静态结构（类图）不对，静态结构是为动态模型完成的功能服务的，所以应该先有需求阶段的顺序图（动态模型），后有静态模型，这是因果关系。 2）类模型中有边界类、控制类和实体类。实体类是客观存在的，所以在需求阶段的静态结构中，主要是指实体类（即业务对象）和重要的边界类、控制类（但一般是抽象类）。 3）顺序图有两种分别在Use Case View和Logical View中出现，用途不同，都可能修改，类图应随之变化。

7.请列举出运用Rose系列工具进行软件开发的全过程。 RUP

9. 生成的代码中能不能体现Use Case图中顺序图所展示出来的业务流程? Rose Real Time模型本身可以执行。 将来Rose也可以在模型中加入代码。

10.在VB语言的模型中，VB Form如何在模型中实现? ordersys.mdl

11.Stereotype的不同类型如何在模型中体现？ A stereotype is, in effect, a new class of modeling element that is introduced at modeling time. It represents a subclass of an existing modeling element with the same form (attributes and relationships) but with a different intent. Generally a stereotype represents a usage distinction. A stereotyped element may have additional constraints on it from the base class. It may also have required tagged values that add information needed by elements with the stereotype. It is expected that code generators and other tools will treat stereotyped elements specially. Stereotypes represent one of the built-in extensibility mechanisms of UML.

自定义stereotype Stereotypes allow you to provide additional distinctions in your model that are not explicitly supported by the UML metamodel. Stereotypes extend the basic modeling elements to create new elements. This makes it easier to add information about modeling elements that may be specific to a project or process. A diagram icon (.wmf, .emf) A small diagram toolbar icon (.bmp) A large diagram toolbar icon A list view icon (.bmp)

Stereotype配置文件 A stereotype configuration file defines a set of stereotypes, including the location of icon files as well as settings that affect the usage and display of the defined stereotypes. Typically, the extension of a stereotype configuration file is .ini, but any extension is allowed. Each stereotype configuration file needs to be located in the Rational Rose installation folder, defined by the InstallDir registry value, and listed in the StereotypeCfgFiles registry section. Note: It is recommended that you add any new stereotypes to the default stereotype configuration file, DefaultStereotypes.ini. Below is a sample configuration file. The sample displays all of the available settings, but the default settings are typically all you need. Select a setting for an explanation of its possible values.

Rose Stereotype Class:Interface Component:EXE Component:DLL Component:ActiveX Component:Application Component:Applet Use Case:business use case Use Case:business use-case realization Use Case:use-case realization Class:control Class:boundary Class:entity Class:business actor Class:business worker Class:business entity Use Case Package:organization unit Logical Package:organization unit Use Case Package:subsystem Logical Package:subsystem Use Case Package:layer Logical Package:layer DependencyRel:refine DependencyRel:extend DependencyRel:include

Rose Stereotype Association:extend Association:include Association:communicate Association:subscribe Association:realize Class:Table Component:Database

12.在建立UML模型过程中，如何才能更好地发现系统中的类？ 1）根据边界类、控制类和实体类的划分思考。 2）参考设计模式。

13.Use Case中的条件分支如何表示？ Sequence Diagram中用注释，或分成多个Sequence Diagram。 直接用Activity Diagram。

1.能否给出一个使用rose开发的项目的文档实例？ SoDA文档模版。

2.使用ROSE如何进行界面设计,采用rose设计时如何与一些可视化的控件联系起来? 以Delphi应用设计为例。