HCOMP Praha, s.r.o. /   / Pojmosloví / UML / A
A

A

abstract

A generalizable element is abstract if it cannot be directly instantiated.

See the entries for abstract class, abstract operation, and abstract use case for more specific information.
 

abstract class

An abstract class is a class that may not have direct instances.

An abstract class has at least one abstract operation. Note, though, that an abstract class can also have concrete operations.
 

abstraction (act)

The term abstraction refers to the act of looking for similarities across sets of things by focusing on the essential common characteristics that make those things different from other kinds of things.

abstraction (dependency)

The term abstraction also refers to a dependency in which the supplier and the client are at different levels of abstraction. For example, there might be an abstraction dependency between an element in the analysis model and a second element in the design model.

The value that results from the evaluation of a mapping expression specifies the nature of the mapping between supplier and client.

The UML defines five kinds of abstraction dependencies:
 

derivation
manifestation
realization
refinement
trace

abstract operation

An abstract operation is an operation that is never instantiated.
 

abstract use case

An abstract use case is a use case that is never directly instantiated, but rather exists for other use cases to reuse.
 

accept call action

An accept call action is an accept event action that represents the receipt of a synchronous call request for an operation specified by a given call trigger.

The action produces a token for a specified output pin.
 

accept event action

An accept event action is an action that waits for the occurrence of an event that meets conditions specified by a given trigger.

There are three kinds of accept event actions:

accept call action
accept signal action
accept time event action


accept signal action

An accept signal action is an accept event action triggered by a signal.
 

accept time event action

An accept time event action is an accept event action triggered by a time event.
 

access

The term access refers to a stereotype attached to a dependency to indicate that within the dependency, the client package has the right to reference the contents of the supplier package.
 

Achieve Acceptable Mission

Within the RUP, Achieve Acceptable Mission is an activity within the Test discipline.

This activity involves focusing efforts on helping the project team achieve the objectives, expressed within the iteration plan, that apply to the current test cycle.
 

action

An action is an executable atomic assignment or computation that receives a set of values from an input pin and produces a change of state and/or the return of values on an output pin.

An action may have one or more local preconditions and one or more local postconditions associated with it.

The UML defines 19 kinds of actions:
 

accept event action
apply function action
clear association action
create object action
destroy object action
invocation action
link action
raise exception action
read extent action
read is classified object action
read link object end action
read link object end qualifier action
read self action
reclassify object action
reply action
start owned behavior action
structural feature action
test identity action
variable action


action execution

An action execution is the execution of a particular action in the context of an activity.
 

action sequence

An action sequence is a noninterruptible sequence of actions.

Note that an action sequence is itself an action, so the rules associated with actions also apply to action sequences.
 

activation

An activation is an execution of an operation.

An activation is represented on a sequence diagram by a focus of control.
 

active class

An active class is a class that represents an independent flow of control.

The instances of an active class are called active objects.
 

active object

An active object is an instance of an active class.

An active object can initiate control activity.
 

active state

An active state is a state that is currently being held by an object within that object's state machine.

A state becomes active when an associated transition fires.
 

active state configuration

The term active state configuration refers to the set of active states that exist at a given time within a particular state machine.
 

activity (UML)

An activity is an ongoing non-atomic (in other words, interruptible) execution.

The flow of execution of an activity is modeled as activity nodes connected by activity edges; tokens control the flow of data and control within the activity.

A simple activity appears in the same form as an action. For a complex activity, one can show the nodes and edges it contains, plus contained actions and flows.
 

activity (Unified Process)

Within the Unified Process, an activity is a tangible unit of work with a well-defined responsibility performed by one or more persons acting in a particular role.

An activity results in one or more artifacts.

activity diagram

An activity diagram is a behavior diagram that illustrates the flows among activities and actions associated with a particular object or set of objects.
 

activity edge

An activity edge is a connection along which tokens flow between activity nodes.

An activity edge may have a guard on it. It may also have a name.

There are two kinds of activity edges: control flows and object flows.
 

activity execution

An activity execution is an execution of a particular activity.
 

activity expression

An activity expression is a textual expression of a particular activity.

An activity expression is meant to express an entire procedure or algorithm. So, it will generally be phrased in terms of a language such as C++ or English.

One uses the reserved word do in conjunction with an activity expression.
 

activity final node

An activity final node is a final node that stops all flows within an activity and thus terminates the activity.
 

activity group

An activity group is a generic grouping construct for activity nodes and activity edges.

There are three kinds of activity groups:

activity partition
interruptible activity region
structured activity node


activity node

An activity node is a placeholder for one or more steps of an activity.

There are three kinds of activity nodes:

control node
executable node
object node


activity parameter node

An activity parameter node is an object node that appears at the beginning or end of a flow to accept inputs to an activity and provide outputs from it.
 

activity partition

An activity partition is an activity group that identifies actions that have some characteristics in common.

An activity partition divides activity nodes and activity edges to constrain, and show a view of, the contained nodes, but it does not affect the flows within the given activity. For example, behaviors of invocations contained by the partition are the responsibility of instances of the classifier represented by the partition.

Activity partitions are represented by swimlanes.
 

activity view

The term activity view refers to those aspects of a system that involve behavior specified as activities connected by control flows.

The activity view is comprised of activity diagrams.

The activity view is a part of the dynamic view.
 

actor

The term actor refers to a coherent set of roles that an entity (human or non-human) outside of the system being modeled plays when interacting with one or more use cases.
 

actual parameter

The term actual parameter is a synonym of argument.
 

add structural feature value action

An add structural feature value action is a write structural feature action that adds one or more values, specified on an input pin, to a structural feature.
 

add variable value action

An add variable value action is a variable action that adds one or more values, specified on an input pin, to a variable.

adornment

An adornment is a graphic or piece of text added to the basic notation of a model element to provide details about that element.

Examples of adornments include notes and visibility symbols.
 

after

The term after is a word that appears within a time expression that models a time trigger.

The event associated with the trigger occurs after the specified time has passed.

aggregate class

The term aggregate class refers to the class that serves as the "whole" within a given aggregation.
 

aggregate object

The term aggregate object refers to an instance of an aggregate class.
 

aggregation

An aggregation is a "whole-part" association within which one element is "part" of the larger "whole" of the other element (the aggregate class).
 

aggregation kind

An enumeration that contains three values:

composite (the class attached to the given association end is a composite class)
none (the class is neither an aggregate class nor a composite class)
shared (the class is an aggregate class)


allInstances

The term allInstances refers to an OCL operation that returns the Set of all instances of a given model element (generally a class) and its descendants.
 

Analysis and Design artifact set

Within the RUP, the Analysis and Design artifact set is the set of artifacts related to the description of how the new system is going to be built.

The Analysis and Design artifact set contains the following artifacts:
 

analysis model
architectural proof-of-concept
data model
deployment model
design model
navigation map
reference architecture
software architecture document
use case realizations-analysis
use case realizations-design
user-interface prototype


Analysis and Design discipline

Within the RUP, the primary purposes of the Analysis and Design discipline are the following:
 
Transform the requirements into a design of the new system.
Evolve a robust architecture for the system.
Shape the design to match up well with the implementation environment.

The following activities comprise the Analysis and Design discipline:
 

Analyze Behavior
Define a Candidate Architecture
Design Components
Design the Database
Perform Architectural Synthesis
Refine the Architecture


analysis class

Within the Unified Process, the term analysis class refers to a stereotype attached to a class to signify that the class is specified to the level of detail appropriate to the analysis model. This generally means that an analysis class contains attributes but not operations.

There are three types of analysis classes:
 

boundary class
control class
entity class


analysis model

Within the Unified Process, the term analysis model refers to a stereotype attached to a model to signify that the model contains analysis packages that work together to realize the functionality specified by the use cases contained within the use case model.

The analysis model is meant to describe and structure the requirements in ways that facilitate the efforts of the project team to understand and work with them. This model can also generally be seen as a "first cut" of the design model.

Within the RUP, the analysis model is part of the Analysis and Design artifact set.
 

analysis package

Within the Unified Process, the term analysis package refers to a stereotype attached to a package to signify that the package organizes  analysis classes and use case realizations-analysis within an analysis model.

An analysis package can also contain other analysis packages.
 

analysis system

Within the Unified Process, the term analysis system refers to a stereotype that refers to the top-level package within an analysis model.
 

Analysis workflow

Within the Unified Process, the purpose of the Analysis workflow is to create an analysis model that refines the requirements of the system and enables the development team to begin to explore the system's internals.

The following activities comprise the Analysis workflow:
 

Analyze a Class
Analyze a Package
Analyze a Use Case
Architectural Analysis


Analyze Behavior

Within the RUP, Analyze Behavior is an activity within the Analysis and Design discipline.

This activity involves transforming the descriptions of user and system behavior captured by the use cases into a set of elements on which design can be based.
 

Analyze a Class

Within the Unified Process, Analyze a Class is an activity within the Analysis workflow.

There are three steps involved in this activity:
 

Identifying the responsibilities associated with each analysis class
Identifying the attributes and relationships associated with those analysis classes
Capturing special requirements associated with those classes

Analyze a Package

Within the Unified Process, Analyze a Package is an activity within the Analysis workflow.

This activity involves ensuring, for each analysis package, that the package is highly independent of other packages and that it realizes a set of classes and/or use cases, and also describing the dependencies among these packages.
 

Analyze the Problem

Within the RUP, Analyze the Problem is an activity within the Requirements discipline.

This activity involves gaining agreement on a statement of the problem the project is intended to solve, identifying stakeholders, and identifying the boundaries and constraints of the system being modeled.


Analyze a Use Case

Within the Unified Process, Analyze a Use Case is an activity within the Analysis workflow.

There are three steps involved in this activity:
 

Identifying the analysis classes needed in order to perform each use case
Distributing the behavior of each use case across the objects associated with those analysis classes
Capturing special requirements associated with each use case

ancestor

The term ancestor refers to any element that sits "above"-in other words, is more general than-a given element within a particular generalization or hierarchy of generalizations.
 

annotational thing

An annotational thing is a comment that describes, illuminates, or remarks about a model element.

A note is an annotational thing.
 

any

The term any refers to an OCL operation that returns an element within a given Collection for which a specified OCL expression resolves to True.
 

any role

Within the RUP, the term any role refers to a generic role used to perform activities that any project member can perform.


any trigger

The term any trigger refers to a message trigger that specifies that a given behavior execution may be triggered by any applicable message trigger except for those specified explicitly on other transactions for a given state.
 

append

The term append refers to an OCL operation that adds a specified element to the end of a given OrderedSet or Sequence.
 

application-general layer

In the context of the Unified Process, the term application-general layer refers to a layer of a system that contains packages and/or subsystems that are reusable within a given business or domain.
 

application-specific layer

In the context of the Unified Process, the term application-specific layer refers to a layer of a system that contains packages and/or subsystems that are not reusable within a given business or domain.
 

apply

The term apply is a stereotype that indicates a profile application.
 

apply function action

An apply function action is an action that applies a primitive function.

An input pin specifies the input values; the action places the return values on an output pin.
 

architect

Within the Unified Process, an architect is a worker who leads and coordinates the technical activities, and the production of the associated artifacts, throughout the project.

The architect also establishes the overall structure for the five views that comprise the architecture.
 

Architectural Analysis

Within the Unified Process, Architectural Analysis is an activity within the Analysis workflow.

This activity focuses on outlining the analysis model and the architecture by identifying analysis packages, key analysis classes and associations among those classes, and common special requirements.
 

Architectural Design

Within the Unified Process, Architectural Design is an activity within the Design workflow.

This activity focuses on outlining the design model and the deployment model and their architectures.

There are four steps involved in this activity:
 

Identifying nodes and their network configurations
Identifying subsystems and their interfaces
Identifying key design classes
Identifying generic design mechanisms that handle common requirements

Architectural Implementation

Architectural Implementation is an activity within the Implementation workflow.

This activity focuses on outlining the implementation model and its architecture. This involves identifying key components and mapping those components to nodes within network configurations.
 

architectural pattern

An architectural pattern is a pattern that defines a structure or behavior for an architectural view of a given model.
 

architectural prototype

Within the RUP, the architectural prototype is the artifact that validates the architecture and serves as the baseline for further development.
 

architectural style

An architectural style is a characteristic of an architecture that reduces the set of available forms and imposes a degree of uniformity on that architecture.

Systems that have similar high-level structures and key mechanisms have similar architectural styles.
 

architectural view

An architectural view is a projection of the key structure and behavior of a given model.
 

architectural view of the analysis model

Within the Unified Process, the term architectural view of the analysis model refers to the view of a system's architecture that encompasses the most significant artifacts of the analysis model, including:
 
analysis packages and the dependencies among them
key analysis classes
important use case realizations-analysis

architectural view of the deployment model

Within the Unified Process, the term architectural view of the deployment model refers to the view of a system's architecture that encompasses the most significant artifacts of the deployment model.
 

architectural view of the design model

Within the Unified Process, the term architectural view of the design model refers to the view of a system's architecture that encompasses the most significant artifacts of the design model, including:
 

design subsystems, their interfaces, and the dependencies among them
key design classes
important use case realizations-design

architectural view of the implementation model

Within the Unified Process, the term architectural view of the implementation model refers to the view of a system's architecture that encompasses the most significant artifacts of the implementation model, including:
 
implementation subsystems, their interfaces, and the dependencies among them
key components

architectural view of the use case model

Within the Unified Process, the term architectural view of the use case model refers to the view of a system's architecture that encompasses the most significant use cases.
 

architecture

The term architecture refers to the overall organizational structure of a given system.

Decisions about these areas are central to an architecture:
 

Selection of structural elements and their interfaces
Behavior of those structural elements, as specified by collaborations
Forming of larger subsystems from structural and behavioral elements
Architectural "style" that guides organization

The UML works well with an architecture comprised of five interlocking views:

deployment view
design view
implementation view
process view
use case view

architecture baseline

Within the Unified Process, the architecture baseline is the collection of models that exist at the end of the Elaboration phase. This baseline represents an internal release of the system being built.
 

architecture-centric

A process is architecture-centric if it involves using the architecture as the key to conceptualizing, constructing, managing, and evolving the system being built.
 

architecture description

Within the Unified Process, the architecture description contains the architectural views of the various models (analysis, deployment, design, implementation, and use case) that represent the system being built.
 

architecture reviewer

Within the RUP, the term architecture reviewer refers to a person playing the role of planning and conducting a formal review of the architecture.
 

argument

An argument is an expression or specific data value corresponding with a parameter.

artifact (RUP)

Within the Unified Process, an artifact is any meaningful internal or deliverable chunk of information that plays a role in the development of the system.

Within the RUP, an artifact belongs to one of nine categories:

Analysis and Design artifact set
Business Modeling artifact set
Configuration and Change Management artifact set
Deployment artifact set
Environment artifact set
Implementation artifact set
Project Management artifact set
Requirements artifact set
Test artifact set


artifact (UML)

Within the UML, an artifact is a classifier that represents a physical piece of information, such as a model, a file, or a table, used or produced by a software development process.

An artifact can also contain other artifacts as part of a composition relationship.

An artifact represents the manifestation of one or more packageable elements.
 

asBag

The term asBag refers to an OCL operation that converts a given OrderedSet, Sequence, or Set into a Bag.
 

asOrderedSet

The term asOrderedSet refers to an OCL operation that converts a given Bag, Sequence, or Set into an OrderedSet.
 

assembly connector

An assembly connector is a connector that connects a required interface or a port on one component to a provided interface or port on another component.
 

asSequence

The term asSequence refers to an OCL operation that converts a given Bag, OrderedSet, or Set into a Sequence.
 

Assess Business Status

Within the RUP, Assess Business Status is an activity within the Business Modeling discipline.

The purpose of this activity is to assess the status of the organization in which the system being modeled will be deployed.
 

asSet

The term asSet refers to an OCL operation that converts a given Bag, OrderedSet, or Sequence into a Set.
 

association

An association is a static (structural) relationship among two or more classifiers (typically classes).

An association contains an ordered list of association ends.

An association can have a name that describes the nature of the relationship.

A link is an instance of an association.

The UML defines two kinds of associations: binary associations and n-ary associations.
 

association class

An association class is a model element that has properties of both an association and a class: it connects two or more classes, and it also has attributes and/or operations.


association class call expression

An association class call expression is a navigation call expression that determines which objects are linked to a given association class by an association.
 

association end

An association end is a structural part of an association that defines the participation of a classifier (usually a class) in that association.

Aspects of an association end include the following:

An aggregation kind value (represented with the appropriate symbol)
A Boolean that indicates whether the association end is navigable from the opposite end
(represented with the appropriate symbol)
A multiplicity value
A name
A value that indicates whether the set of links from the objects that belong to the class
at the other end of the association has some inherent ordering
A visibility kind

Any or all of these aspects may appear on a diagram that shows the association end.
 

association end call expression

An association end call expression is a navigation call expression that determines which objects are linked to a given association end by an association.

at

The term at refers to an OCL operation that returns the element in a specified position within a given OrderedSet or Sequence.
 

atomic

An action or operation is atomic if it cannot be partially executed, or interrupted or terminated by an external event.

Atomic operations are usually assignments and simple computations that occur at definite points of an execution sequence.
 

attribute

An attribute is a named slot within a classifier (typically a class) that describes a range of values that instances of that classifier might hold.

An attribute can have an initial value. Since an attribute is also a kind of structural feature, an attribute also possesses the primary aspects of structural features.

Attributes are represented with their names and other information in the middle compartment of a class box. The full form is

[visibility kind] name [multiplicity] [: type] [= initial value] [{property string}]

The possible values of the property string are contained in the changeability enumeration.

The following is an example of an attribute declaration:

- accountID [1..*] : int {readOnly}

attribute call expression

An attribute call expression is a model property call expression, the evaluation of which determines the value of a given attribute.
 

auxiliary

The term auxiliary refers to a stereotype attached to a class to signify that the class provides some kind of secondary logic or control flow in support of a focus class.
 


partnerská oblast
jméno
heslo
« back
nahoru