UML definitions

Introduction

Some general definitions to key concepts in the process space.

A

Activity

A unit of work a role may be asked to perform.

Activity diagram

Represents a special case of a state machine that is used to model processes involving one or more classifiers.

Actor

Represents someone or something, outside the system, that interacts with the system.

Aggregation

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

Analysis & design

A discipline in the Unified Process, whose purpose is to show how the system's use-cases will be realized in implementation; (general) activities during which strategic and tactical decisions are made to meet the required functional and quality requirements of a system.

Analysis class

An abstraction of a role played by a design element in the system, typically within the context of a use-case realization. Analysis classes may provide an abstraction for several roles, representing the common behavior of those roles. Analysis classes typically evolve into one or more design elements; for example, design classes and/or capsules, or design subsystems.

Application Programming Interface (API)

Represents a software interface that enables applications to communicate with each other. An API is the set of programming language constructs or statements that can be coded in an application program to obtain the specific functions and services provided by an underlying operating system or service program.

Architecture

Represents the highest-level concept of a system in its environment. 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. Architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components, and subsystems.

Artifact

A piece of information that:

1. Is produced, modified, or used by a process,
2. Defines an area of responsibility, and
3. Is subject to version control.

An artifact can be a model, model element, or document. A document can enclose other documents.

Association

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

B

Boundary class

A class used to model communication between the system's environments and its inner workings.

Business actor

Represents someone or something, outside the business, that interacts with the business.

Business entity

A business entity represents a significant and persistent piece of information that is manipulated by business actors and business workers.

Business use-case

A business use-case defines a set of business use-case instances, where each instance is a sequence of actions a business performs that yields an observable result of value to a particular business actor. A business use-case class contains all main, alternate workflows related to producing the "observable result of value".

Business use-case model

A model of the business intended functions. The business use-case model is used as an essential input to identify roles and deliverables in the organization.

C

Class

A description of a set of objects that share the same members.

Component

It represents a non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function. A component should conform to and provides the realization of a set of interfaces.

Component diagram

A diagram that shows the organizations and dependencies that exist among components in a system.

Composition

Represents a form of aggregation association with strong ownership and coincident lifetime as part of the whole.

D

Deployment diagram

A diagram that shows the configuration of run-time processing nodes and the components, processes, and objects that live on them.

Development case

The software-engineering process used by the performing organization. It is developed as a configuration, or customization, of the Unified Process product, and adapted to the project's needs.

Discipline

A discipline is a collection of related activities that are related to a major 'area of concern'. The disciplines in RUP include: Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration & Change Management, Project Management, and Environment.

Document

A document is a collection of information that is ‘intended to be represented’ on paper, or in a medium using a paper metaphor. Web pages may serve as documents.

E

Elaboration

Represents the second phase of the Unified Process where the product vision and its architecture are defined.

Entity class

A class used to model information that has been stored by the system, and the associated behavior. It typically defines a set of entity objects, which participate in several use-cases and typically survive those use-cases.

Environment

Represents a discipline in the software-engineering process, whose purpose is to define and manage the environment in which the system is being developed. Includes process descriptions, configuration management, and development tools.

Executable architecture

An executable architecture is a partial implementation of the system, built to demonstrate selected system functions and properties, in particular, those satisfying non-functional requirements.

Extend-relationship

An extend-relationship from a use-case class A to a use-case class B indicates that an instance of B may include (subject to specific conditions specified in the extension) the behavior specified by A. Behavior specified by several extenders of a single target use-case can occur within a single use-case instance.

F

Feature

An externally observable service provided by the system which directly fulfills a stakeholder needs.

I

Inception

The first phase of the Unified Process, in which the seed idea, request for proposal, for the previous generation is brought to the point of being (at least internally) funded to enter the elaboration phase.

L

Layer

A layer represents a horizontal slice through an architecture.

M

Milestone

Represents the point at which a given iteration formally ends.

Model

Represents a description of a system from a particular perspective, which describes the system in such a way that no additional information is required to understand the system (from that perspective).

Model element

Represents an element that is an abstraction drawn from the system being modeled.

N

Node

A node is a classifier that represents a run-time computational resource, which generally has at least a memory and often processing capability. Run-time objects and components may reside on nodes.

P

Package

Represents a general-purpose mechanism for organizing elements into groups.

R

Refinement

Depicts a relationship that represents a fuller specification of something that has already been specified at a certain level of detail.

Relationship

Represents a semantic connection among model elements.

Requirement

A requirement describes a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed documents.

Risk

Represents an ongoing or upcoming concern that has a significant probability of adversely affecting the success of major milestones.

RUP

Rational Unified Process

S

Scenario

Represents a specific sequence of actions that illustrates behaviors.

Service-Oriented Architecture (SOA)

A service-oriented architecture is a conceptual description of a the structure of a software system in terms of its components and the services they provide, without regard for the underlying implementation of these components, services, and connections between components.

Software requirement

A specification of an externally observable behavior of the system; for example, inputs to the system, outputs from the system, functions of the system, attributes of the system, or attributes of the system environment.

Stakeholder

Represents an individual who is materially affected by the outcome of the system.

Stakeholder need

Represents the business or operational problem (opportunity) that must be fulfilled in order to justify purchase or use.

T

Template

Represents the predefined structure for an artifact.

Traceability

The ability to trace a project element to other related project elements.

U

Use-case

Represents a description of system behavior, in terms of sequences of actions.

Use-case diagram

Represents a diagram that shows the relationships among actors and use-cases within a system.

V

Vision

The user's view of the product to be developed specified at the level of key stakeholder needs and features of the system.