Introduction

This document contains definitions for the terms used within the Object Oriented Analysis and Design Using the UML (OOAD/UML) course. The majority of the definitions were taken from the Rational Unified Process. Some were taken directly from the OOAD/UML course materials, or paraphrased from the UML Userrsquo;s Guide^[1], or a combination of both. Graphics were included where they helped to explain the definition.

Definitions

Abstract Class

A class that cannot be directly instantiated; the opposite of a concrete class.

Abstraction

The essential characteristics of an entity that distinguish it from all other kind of entities and thus provide crisply-defined boundaries relative to the perspective of the viewer.

Action

An action is an operation that is associated with a transition. Actions conceptually take an insignificant amount of time to complete, and are considered non-interruptible. Action names are shown on the transition arrow preceded by a slash.

Active Class

An active class is a class that “owns” itrsquo;s own thread of execution and can initiate control activity, contrasted with passive classes that can only be acted upon. Active classes my execute in parallel (i.e., concurrently) with other active classes.

Activity Diagram

A diagram that models the flow from activity to activity. It is used to model the dynamic view of a system.

Activity

A unit of work a worker may be asked to perform

Actor

Someone or something, outside the system or business that interacts with the system or business.

Aggregation

An association that models a whole-part relationship between an aggregate (the whole) and its parts.

Analysis

The part of the software development process whose primary purpose is to formulate a model of the problem domain. Analysis focuses on what to do, design focuses on how to do it.

Analysis Class

Analysis classes handle primarily functional requirements, and model objects from the 'problem' domain.

Analysis Mechanism

An architectural mechanism used early in the design process, during the period of discovery when key classes and subsystems are being identified. Typically analysis mechanisms capture the key aspects of a solution in a way that is implementation independent. Analysis mechanisms are usually unrelated to the problem domain, but instead are 'computer science' concepts. They provide specific behaviors to a domain-related class or component, or correspond to the implementation of cooperation between classes and/or components. They may be implemented as a framework. Examples include mechanisms to handle persistence, inter-process communication, error or fault handling, notification, and messaging, to name a few.

Architectural Mechanism

An architectural mechanism represents a common solution to a frequently encountered problem. They may be patterns of structure, patterns of behavior, or both.

Architecture

The highest level concept of a system in its environment [IEEE]. The architecture of a software system (at a given point in time) is its organization or structure of significant components interacting through interfaces, those components being composed of successively smaller components and interfaces.

Association Class

An association class is a class that is connected to an association. It is a full-fledged class and can contain attributes, operations and other associations. Association classes allow you to store information about the relationship itself. Such information is not appropriate, or does not belong, within the classes at either end of the relationship.

Association

A relationship that models a bi-directional semantic connection among instances.

Attribute

An attribute defined by a class represents a named property of the class or its objects. An attribute has a type that defines the type of its instances.

Boundary Class

A class used to model communication between the systems environments and its inner workings.

Class

A class is a description of a set of objects that share the same responsibilities, relationships, operations, attributes, and semantics.

Collaboration Diagram

A collaboration diagram describes a pattern of interaction among objects; it shows the objects participating in the interaction by their links to each other and the messages they send to each other.

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. A component conforms to and provides the physical realization of a set of interfaces.

Composition

A form of aggregation with strong ownership and coincident lifetime of the parts by the whole.

Control Class

A class used to model behavior specific to one, or a several use cases.

Dependency

A semantic relationship between two things in which a change to one thing (the independent thing) may affect the semantics of the other thing (dependent thing).

Deployment Diagram

<p

剩余内容已隐藏，支付完成后下载完整资料</p

---

附录A 译文

1.简介

本论文包含了面向对象的分析和设计使用UML（OOAD/ UML）课程对术语的定义。大多数的定义取自合理统一过程。多数情况下是直接从OOAD/ UML的课程材料中获得，也有的是从UML用户指南转述，或两者相组合。图形被列入其中帮助解释定义。

2.定义

2.1抽象类

一个不能被直接实例化的类；这一点与具体类正好相反。

2.2抽象

抽象是指基本特征的对象,它有别于所有其它种类的物体,因此提供简明扼要的概念界限,相对的角度来欣赏.

2.3操作

一个动作是与一个过渡的相关操作。操作概念需要时间来完成一个微不足道的量，被认为是不可中断。操作名称显示在前面有一个斜线过渡箭头。

2.4活动类

一个活动的类是一个“拥有”它自己执行线程并可以启动控制活动的类，对比被动类，只能采取行动。活动类并行（即同时）执行其他活跃类。

2.5活动图

一个图表，模型的流程从活动到活动。它用于一个系统的动态视图建模。

2.6活动

一个单位工作的工人可能被要求执行。

2.7行动者

系统或业务与系统或业务交互之外的某人或某事。

2.8聚合

在一个集合（整体）和部分之间塑造一个整体部分关系的关联。

2.9分析

在软件开发过程中，其主要目的是制定问题域的模型。分析侧重于做什么，设计的重点在于如何做到这一点。

2.10分析类

分析类主要处理功能需求，并从“问题”领域塑造对象。

2.11分析机制

一种用在设计过程早期的架构机制，在探索的时期​​，关键类和子系统正在被确定。通常分析机制获取解决方案的关键环节是独立执行的。分析机制通常是无关的问题域，而是属于“计算机科学”的概念。他们提供一个域相关的类或组件的特定行为，或对应于类和/或组件之间的合作实现。它们可以以一个框架实现。例子包括机制来处理持久化，进程间的通信，错误或故障处理，通知和消息，等等。

2.12构架机制

指共同解决一个频繁遇到的问题的一种架构机制。它们可以是结构的图案，行为，或两者的模式。

2.13架构

一个系统在其环境[IEEE]下最高水平的概念。一个软件系统的体系结构（在给定时间点）是其组织或显著部件通过接口交互的结构，这些组件组成依次更小的部件和接口。

2.14级协会

关联类是连接到关联的类。它是一个可以包含属性，操作和其他关联的完整的类。关联类允许你存储有关关系本身的信息。这样的信息是不恰当的，或者不属于类中关系的任一端。

2.15协会

一种关系，即模型实例间的双向语义连接。

2.16属性

一个类中定义的属性表示类或其对象的指定属性。一个属性具有定义其实例的类型的类型。

2.17边界类

一种用于模拟系统环境和其内部运作之间的通信的类。

2.18级

类是一组共享相同的责任，关系，操作，属性，和语义的对象的描述。

2.19协作图

协作图描述对象之间的互动模式;它示出了通过其联结到彼此和它们相互发送消息参与交互的对象。

2.20组件

一个系统，该系统满足在明确定义的体系结构的上下文中，清除功能的不平凡的，几乎是独立和可替换的部分。一个组件符合并提供一组接口的物理实现。

2.21组成

聚集具有很强的所有权和整个零件的使用寿命一致的表格。

2.22控件类

一种用于特定行为来模拟一个或几个用例的类。

2.23依赖

两件事情之间的语义关系，其中一件事发生变化（独立的事情）可能会影响到其他事情（取决于事情）的语义。

2.24部署图

一个显示运行时处理节点的配置和生活在其中的组件的图表。部署图描述了系统的静态视图。

2.25部署视图

体系结构视图描述了一个或多个系统配置;软件组件（任务，模块）映射在这些计算节点配置的中的。

2.26派生属性

其值的属性可以基于其它属性（多个）的值来计算。

2.27设计

该部分在软件开发过程的主要目的是决定系统将如何实施。在设计过程中，战略和战术决策都是为了满足一个系统所需的功能和质量要求。

2.28设计模型

对象模型描述了实现用例; 作为实施模型及其源代码的抽象。

2.29机制设计

在设计过程中使用的架构机制，其设计的细节正在制定过程中。这些附加的改进都与关联的分析机制有关。一个设计机制承担执行环境中的一些细节，但它不依赖于特定的实现（是一种执行机制）。例如，进程间通信机制的分析可以细化设计为几种机制的进程间通信（IPC）：共享内存，函数调用一样，IPC，IPC信号量为基础的，等等。每个设计机构具有一定的优势和劣势；一个特定的设计机制的选择是通过使用对象的特点确定机制的。

2.30封装

特征的物理定位（例如，属性，行为）到一个单一的黑盒抽象，隐藏其实现（和相关的设计决策背后的公共接口）。封装也称为信息隐藏

2.31实体类

一种用于模型的信息系统存储以及相关行为的类。泛型类在许多用例中重复使用，通常有持续性的特征。一个实体类定义了一组实体对象，参与几个用例通常生存这些用例。

2.32事件

一个事件是发生在某个时间点的发生。在一个状态图中，一个事件是一种刺激，可以触发状态转换的发生。

2.33外观类

一个作为子系统入口点的类。

2.34框架

一个微架构，提供特定领域内的应用程序一个完整的模板。

2.35泛化

一个更一般的元素和一个更具体的元素之间的分类关系。更具体的元素和更一般的元素完全一致，包含附加的信息。更为具体的元素的一个实例允许用在更一般的元素。

2.36实现机制

在执行过程中使用的架构机制。他们是设计机制的改进，并指定确切的实施机制。例如，一个具体实施的进程间通信解析机制是利用一个特定的操作系统的共享内存函数调用的共享存储器设计的机制。并发冲突（不适当同时访问共享存储器）可以使用信号量，或使用一个闭锁机构，能够防止其在对其他执行机制转休息。

2.37实施视图

这说明在开发环境中静态软件元素（代码，数据等陪同工件）的组织，在这两个方面的包装，分层和配置管理（所有权，发布策略，等等）的架构视图。在统一的过程中，它是实现模型视图。

2.38继承

这使得泛化可能的机制;一个机制，创造全类描述了各个阶级段。

2.39接口

即用于指定一个类或组件的服务的操作的集合。

2.40逻辑视图

主营业务相关的类，以及定义关键行为和结构机制（持久性，通信，容错，用户界面​​）的类：描述主要类在系统设计中的一个架构视图。在统一过程中，逻辑视图是设计模型的视图。

2.41留言

一种规范，并期望该活动将接踵而至传达信息的对象之间的通信。

2.42方法

（1）完成某事的定期和系统的方式;详细的，逻辑排序的计划或遵循的程序来完成任务或实现目标。（2）UML 1.1：一个操作的执行，影响操作结果的算法或程序。

2.43模块化

逻辑和物理分解的东西（例如，职责和软件）为小的，简单的组合（例如，各自的要求和类别），从而提高软件工程目标的实现。

2.44多重

规范允许的基数，一套可以承担的范围。

2.45可操纵性

一个角色的可操作性表明这是一个可能通过关联类使用关联的目标类。

2.46节点

一个运行时的物理对象，表示一个计算资源，通常具有至少一个存储器和日常的处理能力。运行时对象和组件可以驻留在节点。

2.47对象

有一个明确的界限和身份，它封装了状态和行为的实体。状态由属性和关系表示，行为由操作和方法来表示。对象是类的一个实例。

2.48操作

一种服务，可以从对象来影响行为的要求

2.49包

造型元素的分组。

2.50模式

一种描述设计片段或集合的类模板以便方案被配置。

2.51多态性

多态性是定义单个接口与多个实现的能力。

2.52流程

（1）任何线程可以并发执行控制逻辑与其他进程。（2）一套旨在达成一部分有序目标的步骤;软件工程的目标是建立一个软件产品或提升现有的产品;工艺工程的目标是开发或增强过程模型;对应于一个业务用例的业务工程。

2.53进程查看

任务（过程）和它们之间的相互作用：描述系统的并发方面的结构图。

2.54特征

指定的值表示一个元素的特征。

2.55实现

分类器之间的语义关系，其中一个分类器指定合同保证另一个分类器进行

2.56责任

一个合同或义务类型或类。

2.57角色

参与特定上下文的实体的行为。

2.58情景

描述用例实例，一个用例的一个子集。

2.59序列图

一个按照时间顺序描述对象之间互动模式的图表; 通过它展示出了它们的“生命线”，并向参与交互的对象发送该消息。

2.60状态

在此期间，对象的生命周期满足一定的条件，执行一些活动，或等待某事件。

2.61状态图

一个状态图显示一个状态机，即一个行为，指定通过响应事件在其寿命期间，连同它的反应和行为的对象的状态序列。

2.62定型

元分类的元素。定型可以为每一个特定的构造值指定语义含义。

2.63子系统

一个模型元素具有一个包的语义，它具有包含其他模型元素和一个类的行为。（子系统的行为是由类或其他子系统包含）。子系统实现一个或多个接口，它定义了可执行的行为。

2.64线

一个独立的由封闭的操作系统进程定义的执行环境和地址空间内执行的计算。

2.65转换

转换是从始发状态更改为继承者状态的一些刺激的结果。

2.66用例

用例定义了一组用例实例，其中每个实例是一个序列的操作的系统执行该产生的值，以一个特定的执行者可观察到的结果。用例类包含与生产“的价值观察的结果事件的所有主，备用流。从技术上讲，一个用例是一类，其实例是场景。

2.67用例模型

制度是应该做的模型与系统的环境。

2.68用例实现

用例实现描述了一个特定用例设计模型中实现，在协作对象。

2.69用例视图

描述关键的用例是如何在系统中进行，重点主要是在建筑显著组件（对象，任务，节点）的架构视图。在统一过程，它是用例模型的视图。

2.70工具类

包含免费的子程序的集合类。

2.71能见度

如何名称可以看出，和由他人使用。

3.简介

开发软件时开展的各项活动，通常是建模为一个软件开发生命周期。软件开发生命周期开始用的要求的识别软件和与正式验证结束所开发的软件反对这一要求。

软件开发生命周期本身并不存在，它是一个整体的一部分的事实产品生命周期。在产品生命周期中，软件将进行维护纠正错误，并符合需求变更。最简单的整体形式是其中产品只是软件，但它可以变得更加复杂，具有多个软件开发的整体系统的各个构成部分包括一个产品。

有许多不同的模式进行软件开发生命周期。一件事所有车型的共同点，就是在生命周期的某个时候，软件必须测试。本文将介绍一些比较常用的软件开发生命周期，特别强调在每个模型的测试活动。

4.连续的生命周期模型

软件开发生命周期开始于一个要求鉴定软件和针对所开发的软件的形式化验证结束要求。传统上，用于软件开发生命周期的车型有过顺序的，通过许多开发进展的明确定义阶段。在连续的阶段通常是由一个V或瀑布图表示。这些车型分别称为为V生命周期模型和瀑布生命周期模型。

图1 V生命周期模型

有其实V和瀑布生命周期模型许多变化，引入不同阶段的生命周期和创造阶段之间的边界不同。下面的一组生命周期阶段适合在与最专业的软件开发人员的做法。

·该要求相，其中用于所述软件的要求收集和分析，产生的软件是一个完整的，明确的规范

需要做的事。

·建筑设计阶段，其中对于实施软件架构的要求，设计并指定，识别内的组件

软件和组件之间的关系。

图2瀑布生命周期模型

·本详细设计阶段，其中每个组件的详细的实施是指定。

·该编码和单元测试阶段，其中软件的每个部件进行编码和测试，以验证它忠实地实现了详细设计。

·该软件集成阶段，其中逐渐变大的组中试验软件组件集成和测试，直至软件可以作为一个整体。

·该系统集成阶段，其中该软件被集成到整体产品和测试。

·验收测试阶段，在测试中被应用，并且目睹验证软件忠实实现指定要求。

软件规格将是前三个阶段这个生命周期模型的产品。该剩下的四个阶段都涉及测试软件在不同的水平，需要测试规格针对该测试将要进行作为输入到每个这些阶段。

5.进步发展的生命周期模型

环比V和瀑布生命周期模型代表的软件一个理想化的模型发展。其他生命周期模型可用于多种原因，诸如挥发

剩余内容已隐藏，支付完成后下载完整资料

---

资料编号：[499558]，资料为PDF文档或Word文档，PDF文档可免费转换为Word