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:
- Is produced, modified, or used by a process,
- Defines an area of responsibility, and
- 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.
