icon to see where you can go within the five books to learn more about a given term.Please feel free to send comments to kendall@softdocwiz.com.
Click here to go back to the home page of my company, Software Documentation Wizards.
Happy reading!
Note: This Dictionary may be considered to be in the public domain. However, if you would like to use it for commercial purposes, kindly do the following: (1) send me E-mail telling me what you plan to do, and (b) add a link to http://softdocwiz.com so your customers can find out what else I have to offer in the way of software documentation.
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 can, however, 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 source and the target are at different levels of abstraction (for instance, within different models).
There are four kinds of abstraction dependencies:
 | derivation |
| realization |
| refinement |
| trace |
abstract superclasses rule
The abstract superclasses rule states that leaf classes should be abstract and non-leaf classes should be concrete.
This "rule" is actually more of a solid design principle. Under this scheme, an abstract be superclass contains all of the be methods to be inherited, while the concrete be subclasses contain versions of those methods that are tailored appropriately.
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.
access
The term access refers to a stereotyped dependency within which the source package has the right to reference the contents of the target package.
action
An action is an executable atomic computation that results in a change of state or the return of a value.
The UML defines eight kinds of actions:
| assignment action |
| call action |
| create action |
| destroy action |
| return action |
| send action |
| terminate action |
| uninterpreted action |
The UML does not specify the syntax of action expressions. They are generally associated with programming languages.
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.
action state
An action state is a state whose purpose is to execute an action and then fire a transition to another state.
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 whose instances are active objects.
An active class models a family of processes or threads.
active object
An active object is an instance of an active class.
An active object owns a thread and 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 within a state machine.
activity (Unified Process)
Within the Unified Process and the RUP, an activity is a tangible unit of work with a well-defined responsibility that a worker performs.
An activity results in one or more artifacts.
activity diagram
An activity diagram is a diagram that shows flows between activities.
An activity diagram shows an activity graph.
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, you will generally phrase an activity expression in terms of a language such as C++ or English.
You use the reserved word do in conjunction with an activity expression.
activity graph
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.
activity state
An activity state is a state whose purpose is to execute an activity and then fire a transition to another state.
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 is a keyword which 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.
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 keyword that you use in conjunction with a time expression to model a time event.
aggregate
The term aggregate refers to the class that serves as the "whole" within a given aggregation.
aggregation
An aggregation is a "whole-part" association within which one element is "part" of the larger "whole" of the other element.
allInstances
The term allInstances refers to an oclOperation that returns the Set of all instances of a given model element, including subtypes.
allSupertypes
The term allSupertypes refers to an oclOperation that returns the Set of all supertypes associated with a given model element.
analysis and design workflow
Within the RUP, the purpose of the analysis and design workflow is to translate the requirements into a specification that describes how the new system is to be built and implemented.
The primary artifact of the analysis and design workflow is the design model.
analysis class
An analysis class is a class that represents a fairly high-level abstraction of one or more classes from a given system's design.
There are three types of analysis classes:
| boundary class |
| control class |
| entity class |
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 design set.
analysis package
An analysis package is a stereotyped package used to organize analysis classes and use case realizations within an analysis model.
An analysis package can also contain other analysis packages.
analysis system
The term analysis system is a stereotype that refers to the top-level package within an analysis model.
analysis workflow
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:
| Architectural Analysis |
| Analyze a Use Case |
| Analyze a Class |
| Analyze a Package |
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 |
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 a Use Case
Analyze a Use Case is the second activity within the analysis workflow.
There are three steps involved in this activity:
| identifying the analysis classes that are 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 |
annotational thing
An annotational thing is a comment that describes, illuminates, or remarks about an element of a model.
A note is an annotational thing.
append
The term append refers to an oclOperation that adds a specified element to the end of a given Sequence.
application-general layer
The term application-general layer refers to a layer of a system which contains packages and/or subsystems that are reusable within a given business or domain.
application-specific layer
The term application-specific layer refers to a layer of a system which contains packages and/or subsystems that are not reusable within a given business or domain.
architect
The architect is the 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
Architectural Analysis is the first 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
Architectural Design is the first 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 |
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 the 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 an attribute 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
The term architectural view of the analysis model refers to the view of a system' 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 |
architectural view of the design model
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 |
| implementation subsystems, their interfaces, and the dependencies among them |
| key components |
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 |
Five interlocking views comprise an architecture:
| deployment view |
| design view |
| implementation view |
| process view |
| use case view |
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
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 worker who plans and conducts a formal review of the architecture.
argument
An argument is a specific value corresponding with a parameter.
artifact
An artifact is a piece of information, such as a document or a model, that is produced, modified, and/or used within a process.
Within the RUP, an artifact belongs to one of five categories:
| deployment set |
| design set |
| implementation set |
| management set |
| requirements set |
association (relationship)
An association is a relationship that describes a set of links between or among objects.
An association can have a name that describes the nature of this relationship. You can put a triangle next to this name to indicate the direction in which the name should be read.
An association contains an ordered list of association ends. An association with exactly two association ends is called a binary association; an association with more than two ends is called an n-ary association.
association (stereotype)
The term association also refers to a stereotype attached to a link end to signify that the corresponding object is visible via an association.
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 end
An association end is a structural part of an association that defines the participation of a class in that association.
The following are the primary aspects of an association end:
| aggregation (aggregate indicates that the object attached to the association end is an aggregation; composite indicates that the attached object is a composite; i>none indicates that the object is neither an aggregation nor a composite) |
| changeability |
| multiplicity |
| navigability |
| visibility |
associationEnds
The term associationEnds refers to an oclOperation that returns the Set of association ends belonging to a given model element.
association generalization
The term association generalization refers to a generalization that involves two associations.
association role
An association role is an association between two objects that applies only in a certain context, as specified by a given collaboration.
asynchronous action
An asynchronous action is a request that an object makes without waiting for a response.
at
The term at refers to an oclOperation that returns the element in a specified position within a given 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 property of a class that describes a range of values that instances of that class might hold.
The following are the primary aspects of an attribute:
| changeability |
| initial value |
| multiplicity |
| type |
| visibility |
attributes
The term attributes refers to an oclOperation that returns the Set of attributes belonging to a given model element.
Bag
A Bag is a Collection of elements, each of which may appear more than once.
You end up with a Bag when you navigate through more than one association whose multiplicity is greater than 1.
baseline
A baseline is a release of artifacts, which have been reviewed and approved by the appropriate stakeholders, that together form an agreed-on basis for further evolution or development of the system.
A baseline can be changed only via a formal procedure, such as a change request.
become
The term become is a stereotyped flow dependency within which the target object is a transformed version of the source object which replaces that object.
This transformation can result in different values, roles, location,and/or state for the target object.
behavior
The term behavior refers to the observable effects of an operation or an event, including its results.
behavioral feature
A behavioral feature is a dynamic feature of a model element, such as an operation or a method.
behavioral thing
A behavioral thing is a verb that represents a dynamic behavior through space and over time.
There are two primary kinds of behavioral things: interactions and state machines.
behavioral view
The term behavioral view is a view of a given model that focuses on the behavior of the instances within the system being modeled.
bind
The term bind is a keyword that signifies a binding.
When bind is present, there must also be a list of actual parameters that match up with the given template's formal parameters.
binding
A binding is a dependency within which the source instantiates the target template to produce a new model element that uses the specified actual parameters.
Boolean
The term Boolean refers to an enumeration that contains two values: True and False.
Boolean expression
The term Boolean expression refers to an expression that resolves to a Boolean value.
boundary class
The term boundary class refers to a stereotyped class used to model the interaction between an actor and the system.
bound element
A bound element is a model element that results from a binding.
branch
A branch is a place within a state machine where a trigger leads to more than one possible outcome, each of which has an associated guard condition or the keyword else.
broadcasting
The term broadcasting refers to what happens when an object sends a signal to a set of objects.
build
A build is an executable version of part of a system or an entire system.
buiness case
The term business case refers to an artifact that presents the case for going forward with a given project.
buiness designer
The term business designer refers to a worker who specifies the business workers and business entities needed to realize one or more business use cases and distributes the behavior of that use case to those workers and entities.
business entity
A business entity is something that one or more workers use in some fashion in the context of a use case within a business use-case model.
A business entity is also an artifact.
business modeling workflow
Within the RUP, the purpose of the business modeling workflow is to build a business use-case model and a business object model in order to achieve the following goals:
| understand the structure and dynamics of the organization |
| ensure that the stakeholders have a common understanding of the organization |
| discover the requirements that the new system must satisfy for the organization |
buiness object model
A business object model shows how the use cases within the business use-case model are "performed" in terms of interacting workers, business entities, and work units.
A business object model is generally represented by interaction diagrams and activity diagrams.
Within the RUP, the business object model is part of the requirements set.
buiness-process analyst
Within the RUP, a business-process analyst is a worker who leads and coordinates the effort to build the business use-case model.
business use-case model
A business use-case model is a model of the intended functions of a given business, stated in terms of actors (in this case, roles external to the business) and use cases (which represent processes here).
A business use-case model is generally represented by use case diagrams.
Within the RUP, the business use-case model is part of the requirements set.
call (act)
A call is an invocation of an operation during the execution of a procedure.
call (dependency)
The term call also refers to a stereotyped dependency within which the source operation invokes the target operation.
call action
A call action is an action that results in the invocation of an operation.
call event
A call event is an event that represents the dispatch of an operation.
cardinality
The term cardinality refers to the number of elements in a given set.
changeability
The term changeability refers to a property whose value indicates whether a given attribute or link can change after being initialized.
The allowable values of the changeability property are as follows:
| addOnly (for an attribute whose multiplicity is greater than 1, you can add additional values, but you cannot change or delete a value once you have added it; for a link, you can add new links from an object on the opposite side of the given association) |
| changeable (for an attribute, you can add, change, and delete values without restriction; for a link, you can add, change, and delete links between the objects connected by the given association without restriction) |
| frozen (for an attribute, you cannot add, change, or delete any values; for a link, you can add new links from an object being created on the opposite side of the given association, but you cannot change or delete a link once you have added it) |
change request
A change request is a formal written request, associated with a particular originator and a specified root cause, to fix a defect, modify a requirement, or otherwise effect a meaningful change to the system being developed.
Within the RUP, change requests are part of the management set.
child
The term child refers to the more specific element within a given generalization relationship.
class
A class is a named description of a set of objects that share the same attributes, operations, relationships, and semantics. These objects can represent real-world things or conceptual things.
See the entries for abstract class, analysis class, and design class for information about the various forms that a class can take within the UML.
class diagram
A class diagram is a diagram that shows a set of classes, interfaces, and/or collaborations and the relationships among these elements.
You generally use class diagrams in connection with the structual elements of the design view and the process view.
classifier
A classifier is a model element that describes behavioral features and/or structural features.
The UML defines 11 kinds of classifiers:
| actor |
| class |
| classifier role |
| class-in-state |
| component |
| data type |
| interface |
| node |
| signal |
| subsystem |
| use case |
class-in-state
A class-in-state is a combination of a class and a state in which objects of that class can reside.
client
The term client refers to the element within a dependency that requests one or more services from the supplier.
code reviewer
Within the RUP, a code reviewer is a worker who plans and conducts source code reviews.
collaboration
A collaboration is a named collection of classes, interfaces, and other elements that work together to provide some behavior that is bigger than the behavior represented by the sum of the parts. A collaboration realizes either a or an operation.
The static part of a collaboration describes collaboration roles that objects and links may play in instantiations of the collaboration. The dynamic part of a collaboration consists of one or more dynamic interactions that show message flows over time.
The behavioral parts (represented by the objects within its interactions) must be consistent with the structural parts: in other words, the objects within its interactions must be instances of its classes.
collaboration diagram
A collaboration diagram is an interaction diagram that focuses on the structural organization of the objects.
Collaboration diagrams and sequence diagrams are semantically equivalent, which means you can convert one type of diagram to the other without losing any information. However, a collaboration diagram has two key features that a sequence diagram does not: optional stereotypes, such as local and self, for the paths between objects, and sequence numbers.
collaboration role
A collaboration role is a slot for an object or a link within a collaboration.
There are two types of collaboration roles: association roles and classifier roles.
collect
The term collect refers to an oclOperation that creates a Collection which contains the values that result from evaluating a specified expression for each of the elements in a given Collection.
Collection
Collection is the abstract supertype of Bag, Sequence, and Set.
You can perform any of the following operations on a Collection:
| collect |
| count |
| equals |
| excluding |
| exists |
| forAll |
| includes |
| includesAll |
| including |
| intersection |
| isEmpty |
| iterate |
| notEmpty |
| reject |
| select |
| size |
| sum |
| union |
The extend and include relationships are both combinations.
comment
A comment is a piece of text that provides arbitrary information associated with one or more model elements.
communication association
A communication association is an association that describes a commmunication relationship between two elements.
For instance, two nodes might belong to a communication association within a deployment view, as would an actor and a use case within a use case view.
complete
The term complete is a constraint attached to a generalization to signify that all children have been specified for that generalization and that no more can be specified.
completion transition
A completion transition is a triggerless_transition that is triggered by the completion of activity in a given source state.
complex transition
A complex transition is a transition that has more than one source state (this is a join) and/or more than one target state (this is a fork).
component
A component is a named physical and replaceable part of a system that represents physical packaging of otherwise logical elements and that conforms to, and provides the realization of, one or more interfaces.
component diagram
A component diagram is a diagram that shows a set of components and the relationships among them.
component engineer
A component engineer is a worker who is responsible for artifacts within several workflows:
composite class
A composite class is a class that serves as the "whole" within a composition relationship.
composite object
A composite object is an instance of a composite class.
composite state
A composite state is a state comprised of either concurrent substates or disjoint substates.
Given two or more substates at the same level, an object will be in one sequential substate, but each of the concurrent substates.
composition
The term composition refers to an aggregation within which the "part"s and the larger "whole" share lifetimes.
A given model element can be part of only one composition relationship at a time.
concrete
A generalizable element is concrete if it can be directly instantiated.
See the entries for concrete class, concrete operation, and concrete use case for more specific information.
concrete class
A concrete class is a class that may have direct instances.
An concrete class cannot have abstract operations, however.
concrete operation
A concrete operation is an operation that has an implementation.
concrete use case
A concrete use case is a use case that is initiated by an actor and that represents a complete sequence of actions to be performed by the system being built.
A concrete use case may reuse the behavior associated with one or more abstract use cases.
concurrency (property)
The term concurrency refers to a property whose value indicates how a given operation will respond in the face of more than one concurrent call to it.
The allowable values of the concurrency property are as follows:
| concurrent (multiple calls may come in simultaneously, and they can all proceed concurrently) |
| guarded (multiple calls may come in simultaneously, but only one can be addressed at a time) |
| sequential (only one call may come in at a time) |
These activities perform independently unless synchronization points have been explicitly defined.
concurrent substate
A concurrent substate is a substate that can exist simultaneously with other substates within a composite state.
conditional thread
A conditional thread is a region on an activity graph that begins with an output segment from a fork, which has an associated guard condition, and ends with an input segment of a join.
configuration and change management workflow
Within the RUP, the purpose of the configuration and change management workflow is to track, and maintain the integrity of, project assets as they evolve in the presence of changes.
configuration management plan
A configuration management plan defines the configuration management policies and practices to be used on the project.
configuration manager
Within the RUP, the configuration manager is the worker who provides the overall configuration management infrastructure and environment for the development team.
conflict
A conflict occurs when there is the chance for some kind of contradiction or ambiguity within a given model.
For instance, a conflict would arise if a subclass inherits two attributes, both with the same name, from two superclasses, or if an event enables more than one transition.
constraint (mechanism)
A constraint is an extensibility mechanism that allows you to create conditions and restrictions, stated as Boolean expressions, that apply to model elements.
You can specify a constraint using free-form text or the more precise Object Constraint Language (OCL).
Note that a constraint represents an assertion, not an executable mechanism.
The following constraints are predefined within the UML:
| complete |
| destroyed |
| disjoint |
| implicit |
| incomplete |
| new |
| or |
| ordered |
| overlapping |
| transient |
| xor |
construction phase
The construction phase is the phase of a development project in which the architecture baseline grows to become the full-fledged system.
The primary goal of this phase is to produce a product that is ready to put in the hands of its customers.
constructor
A constructor is an operation, which has class scope, that creates and initializes an instance of a class.
container
A container is an object, designed to contain other objects, that provides operations you can use to access its contents directly or iterate through them.
Arrays and sets are examples of containers.
context (OCL)
Within the OCL, the term context refers to the model element with which a given invariant, precondition, or postcondition is associated.
context (UML)
Within the UML, a context is a piece of a model that provides the environment for a set of related elements of that model.
control class
A control class is a stereotyped class used to represent coordination, sequencing, transactions, and/or control of one or more objects associated with other classes, or to encapsulate control related to a given use case.
control flow
A control flow is a combination of (a) the relationship between an action and the actions that occur before and after it and (b) the relationship between that action and its input and output objects.
copy
The term copy is a stereotyped flow dependency within which the target object is an exact copy of the source object.
Note that once the copy occurs, the target object is independent of the source object.
count
The term count refers to an oclOperation that returns the number of occurrences of a specified element within a given Collection.
course developer
Within the RUP, a course developer is a worker who develops training material with which users are taught how to use the new system.
create (behavioral feature)
The term create refers to a stereotype on a behavioral feature which indicates that the feature creates an instance of the enclosing classifier.
create (dependency)
The term create also refers to a stereotype on a dependency which indicates that the client classifier creates one or more instances of the supplier classifier.
create (event)
The term create also refers to a stereotype on an event which indicates that the event involves the creation of an instance enclosing the appropriate state machine.
create action
A create action is an action that results in the instantiation and initialization of an object.
creation
The term creation refers to the instantiation and initialization of an instance.
current event
The term current event refers to the event that triggered a run-to-completion step within the execution of a given state machine.
database designer
Within the RUP, a database designer is a worker who designs one or more logical database schemas and/or physical databases for the new system.
data type
A data type describes a set of values that have no identities and cannot be changed.
"Primitive" data types include numbers, strings, and time. Enumerations, except for Boolean, are user-definable data types.
data value
A data value is an instance of a data type.
default value
A default value is a data value supplied by an entity external to the given model.
defect
A defect is a symptom of a problem in the system.
deferred event
A deferred event is an event that is not recognized while the associated object is in a particular state.
delegation
An object performs a delegation when it issues a message to another object in response to an initial message.
dependency
A dependency is a relationship between two things within which a change to one thing (the independent element) may affect the semantics of the other thing (the dependent element).
The dependent element is generally referred to as the client or the target. The independent element is generally referred to as the supplier or the source.
There are five basic kinds of dependencies:
| abstraction |
| binding |
| combination |
| permission |
| usage |
deployment manager
Within the RUP, the deployment manager is the worker who plans and oversees the transition of the new system to the user community.
deployment model
A deployment model is a stereotyped model that describes the physical distribution of the system being built, in terms of how functionality is distributed among computational nodes.
Within the RUP, the deployment model is part of the design set.
deployment set
Within the RUP, the deployment set is a set of artifacts related to the physical deployment of a system.
The deployment set contains the following artifacts:
| executable baselines |
| release notes |
| user support material (including user manual, installation material, and training material) |
The deployment view is captured primarily on deployment diagrams, and also on interaction diagrams, statechart diagrams, and activity diagrams.
The deployment view is a part of the static view. The deployment view is also one of the five interlocking views that comprise the architecture.
deployment workflow
Within the RUP, the purpose of the deployment workflow is to deliver the new system to its customers.
derivation
A derivation is a dependency within which the target can be computed or inferred from the source.
You model a derivation using the derive stereotype.
derive
The term derive is a stereotype that signifies a derivation.
derived element
A derived element is an element that can be computed or inferred from other elements.
descendant
The term descendant refers to any element that sits "below"--in other words, is more specific than--a given element within a particular generalization.
descriptor
A descriptor is a model element that describes the common properties of a set of instances.
A descriptor has both an intent and an extent.
Design a Class
Design a Class is the third activity within the design workflow.
There are eight steps involved in this activity:
| outlining each design class in terms of analysis classes and/or interfaces |
| identifying the operations that each design class needs to provide |
| identifying the attributes that each design class needs |
| identifying the associations and aggregations connected with those design classes |
| identifying generalizations in which those design classes should participate |
| describing methods that those design classes should implement |
| describing the possible states of objects instantiated from those design classes |
| handling special requirements associated with those design classes |
There are three steps involved in this activity:
| ensuring, for each subsystem, that the subsystem is highly independent of other subsystems and their interfaces |
| ensuring that each subsystem provides the appropriate interfaces |
| ensuring that each subsystem offers a correct realization of the operations behind those interfaces |
There are five steps involved in this activity:
| identifying the design classes that are needed in order to perform each use case |
| distributing the behavior of each use case across the objects associated with those design classes |
| identifying the necessary subsystems and interfaces |
| describing the interactions of those subsystems |
| capturing requirements, associated with each use case, that should be addressed during implementation |
designer
Within the RUP, a designer is a worker who defines the responsibilities, operations, attributes, and relationships for one or more classes, and also determines how those definitions should be adjusted with regard to implementation.
design model
A design model is a stereotype model that contains a hierarchy of design subsystems.
The design model is intended to describe the physical realizations of the system's use cases. This model also serves as an abstraction of the system's implementation.
Within the RUP, the design model is part of the design set.
design pattern
A design pattern is a pattern that defines a structure or behavior for the design view of a given model.
design reviewer
Within the RUP, a design reviewer is a worker who plans and conducts a formal review of the design model.
design set
Within the RUP, the design set is the set of artifacts related to the description of how the new system is going to be built.
The design set contains the following artifacts:
| analysis model |
| data model |
| deployment model |
| design model |
| process model |
| software architecture description |
| test model |
A design subsystem can also contain other design subsystems.
design system
The term design system refers to a stereotype that refers to the top-level package within the design model.
Design Test
Design Test is the second activity within the test workflow.
This activity involves identifying and describing integration, system, and regression test cases for each build and identifying and structuring test procedures.
design view
The term design view refers to the set of classes, interfaces, and collaborations that together describe the problem space and the solution space associated with a given system. This view exists to specify the functional requirements of the system.
The design view is captured in class diagrams, object diagrams, interaction diagrams, statechart diagrams, and activity diagrams.
The design view is one of the five interlocking views that comprise the architecture.
design workflow
The purpose of the design workflow is to create a design model that describes the physical realizations of the use cases and serves as an abstraction of the system's implementation.
The following activities comprise the design workflow:
| Architectural Design |
| Design a Use Case |
| Design a Class |
| Design a Subsystem |
destroy (behavioral feature)
The term destroy is also a stereotype on a behavioral feature which indicates that the feature destroys an instance of the enclosing classifier.
destroy (event)
The term destroy is also a stereotype on an event which indicates that the event involves the destruction of an instance enclosing the appropriate state machine.
destroy action
A destroy action is an action that results in the destruction of a target object.
destroyed
The term destroyed refers to a stereotype attached to a classifier role or association role to signify that an instance of the role exists before execution of the given interaction, but will cease to exist some time before that execution is complete.
destruction
The term destruction refers to the elimination of an object and the reclaiming of the resources it was controlling.
Destruction includes the elimination of links associated with the given object. If the object is a composite object, all of its parts are eliminated as well.
Detail a Use Case
Detail a Use Case is the third activity within the requirements workflow. It involves describing the basic and alternate courses of action (flows of events) through each use case in detail, including how the use case starts and ends and the involvement of actors.
diagram
A diagram is a graphical presentation of a collection of model elements. This presentation is a projection of those elements of a given model.
Most UML diagrams show model elements as vertices and the relationships among those elements as arcs.
The UML defines nine types of diagrams:
| activity diagram |
| class diagram |
| collaboration diagram |
| component diagram |
| deployment diagram |
| object diagram |
| sequence diagram |
| statechart diagram |
| use case diagram |
direct instance
An object is a direct instance of a given class if that class describes the instance and no descendant class also describes that object.
discriminator
A discriminator is a pseudoattribute that selects a child element from a set of children within a generalization relationship.
disjoint
The term disjoint is a constraint attached to a set of generalizations to signify that given multiple inheritance, no object can be an instance of more than one child within the set.
disjoint substate
A disjoint substate is a substate that cannot exist simultaneously with other substates within a composite state.
distribution unit
A distribution unit is a set of objects or components allocated to a node as a group.
do
The term do is a reserved word used in conjunction with an activity expression in the context of an activity_graph or a state machine.
document
A document is a stereotyped component that represents a document.
documentation
The term documentation refers to a tagged value that specifies a comment, description, or explanation associated with the element, such as a class, to which it is attached.
domain model
A domain model captures the most important types of business objects and real-world objects and concepts that exist, and also events that transpire, in the environment in which a given system will work.
A domain model is generally represented by class diagrams.
dynamic classification
The term dynamic classification refers to a variation of generalization in which an object can change type or role.
dynamic concurrency
The term dynamic concurrency refers to the situation in which an activity state represents concurrent execution of more than one independent computation.
dynamic view
The term dynamic view refers to those aspects of a given model having to do with the specification and implementation of behavior over time.
Four views comprise the dynamic view:
| activity view |
| interaction view |
| state machine view |
| use case view |
The primary goal of this phase is to produce an architecture baseline that can serve as the foundation for the new system.
element
An element is an atomic constituent of a model.
else
The term else is a keyword that you use in conjunction with a branch to indicate the path to be taken if the guard conditions on the associated paths all evaluate to False.
entity class
An entity class is a stereotyped class used to model long-lived information that may be persistent.
entry action
An entry action is an action that is performed when an object enters a given state.
You denote an entry action with the reserved word entry.
enumeration
The term enumeration is a keyword that signifies a user-definable data type that has an ordered list of literal values.
Note that Boolean is a predefined enumeration.
environment workflow
Within the RUP, the purpose of the environment workflow is to support the development team with processes and tools.
equals
The term equals refers to an OCL operator that works on Collections.
| For two Sets, an operation containing the equals operator returns True if both Sets contain the same elements. |
| For two Bags, that operation returns True if both Bags contain the same elements the number of times each of those elements appears in each Bag is also the same. |
| For two Sequences, that operation returns True if both Sets contain the same elements and the order of those elements is the same within both Sequences. |
This activity involves evaluating the testing efforts within a given iteration by comparing the results with the goals described in the test plan.
event
An event is a noteworthy occurrence that has a location in time and space.
Within a state machine, the occurrence of an event can trigger a transition.
An internal event passes between objects in the system; an external event passes between the system and an actor.
Within the UML, there are four kinds of events:
| call events |
| change events |
| signal events |
| time events |
exception
The term exception is a keyword that signifies a signal that you use in conjunction with a class to model an exception that the given class can throw or receive in response to a failure during system execution.
excluding
The term excluding refers to an oclOperation that works on Collections.
| For a Set, the including operation removes a given element. |
| For a Bag or a Sequence, the operation removes all occurrences of a given element. |
exists
The term exists refers to an oclOperation that returns True if a specified expression is True for at least one element within a given Collection.
exit action
An exit action is an action that is performed when an object leaves a given state.
You denote an exit action with the reserved word exit.
export
In the context of a package, to export an element is to make it accessible outside of the namespace to which it belongs by setting its visibility to a level that permits it to be seen by other packages.
export interface
An export interface is an interface that a component provides to other components.
expression
An expression is a string that represents a statement to be interpreted by a language outside of the UML. This statement generally resolves to a set of instances or values, or results in the performance of a specific action within a given context.
The UML defines six kinds of expressions:
| action expression |
| Boolean expression |
| object set expression |
| procedure expression |
| time expression |
| type expression |
You generally use an extend dependency to model optional system behavior, such as error handling, or behavior that only occurs under certain conditions.
extensibility
The term extensibility refers to the ability to extend the UML in controlled ways.
The UML defines three extensibility mechanisms:
| constraint |
| stereotype |
| tagged value |
extent
An extent is the set of instances associated with a descriptor.
external transition
An external transition is a transition that causes a change from the source state to the target state.
facade
A facade is a stereotyped package that contains only references to model elements owned by another package.
feature
A feature is a property encapsulated, as part of a list, within a classifier.
There are two types of features: behavioral features and structural features.
file
A file is a stereotyped component which represents a file that contains source code or data.
final state
A final state is a pseudostate which indicates that the execution of the enclosing composite state is complete.
Find Actors and Use Cases
Find Actors and Use Cases is the first activity within the requirements workflow.
There are four steps involved in this activity:
| finding the actors |
| finding the use cases |
| writing brief descriptions of each use case |
| describing the use-case model |
first
The term first refers to an oclOperation that returns the first element in a given Sequence.
flow
A flow is a type of dependency that relates two versions of the same object, and thus the transformation of one state of that object into another, at successive points in time.
The UML defines two types of flows: become and copy.
flow of events
The term flow of events refers to a tagged value whose value contains a text description of the sequence of actions associated with a use case.
flow of events--analysis
The term flow of events--analysis refers to a tagged value whose value contains a text description of a use-case realization--analysis.
flow of events--design
The term flow of events--design refers to a tagged value whose value contains a text description of a use-case realization--design.
focus of control
A focus of control is a tall, thin rectangle on a sequence diagram that shows the period of time during which a given object has control.
forAll
The term forAll refers to an oclOperation that returns True if a specified expression is True for all elements within a specified Collection.
fork
A fork is a complex transition within which one source state is replaced with two more more target states.
formal argument
The term formal argument is a synonym of parameter.
framework
A framework is a stereotyped package which represents an architectural pattern that provides an extensible template for applications within a domain.
friend
The term friend refers to a stereotyped dependency within which the source (for instance, a package) has the right to access certain elements of the target, even though the source does not otherwise have the appropriate permission in terms of the target's visibility.
full descriptor
A full descriptor is the complete description of all of the attributes, operations, and associations belonging to a given instance.
functional requirement
The term functional requirement refers to an action that the new system must be able to perform.
functional view
The term functional view refers to the set of functions and operations that provide a system's functionality.
The data flow diagram (DFD), which the UML does not directly support, is at the heart of the functional view.
generalizable element
A generalizable element is a model element that can participate in a generalization relationship, as a parent and/or a child.
There are three properties that you can assign to a generalizable element.
| If the abstraction property is True, the element is abstract. |
| If the leaf property is True, the element is a leaf. |
| If the root property is True, the element is a root. |
The phrase "kind of" is often used in connection with generalization: the child is a kind of the parent.
Generalization is commonly found in connection with classes. See the entries for association generalization and use case generalization for information about other uses for generalization.
generic iteration workflow
The generic iteration workflow includes the five core workflows--requirements, analysis, design, implementation, and test--and also planning, which precedes the requirements workflow, and assessment, which follows the test workflow.
This workflow describes concrete iteration workflows for each phase of the project.
global
The term global refers to a stereotype attached to a to signify that the corresponding object is visible because it is part of a global scope relative to the object at the other end of the link.
glossary
A glossary is a list of terms of relevance to the business.
Within the RUP, the glossary is part of the requirements set.
grouping thing
A grouping thing is a device for organizing elements within a model.
A package is a grouping thing. <
guard condition
A guard condition is a Boolean expression that must resolve to True before the associated transition can fire.
The names that appear within a guard condition must be names of parameters of the associated trigger and/or attributes of the object that owns the enclosing state machine.
guideline
Within the RUP, a guideline is a rule, recommendation, or heuristic that supports one or more activities.
history state
A history state is a pseudostate which indicates that the enclosing composite state remembers a previously active substate after the associated object leaves that state.
A shallow history state remembers only the outermost nested state. A deep history state remembers the innermost nested state at any depth.
identity
An object's identity is the property that uniquely identifies that object.
Implement a Class
Implement a Class is the fourth activity within the implementation workflow.
There are four steps involved in this activity:
| outlining the file that contains the source code for each design class |
| generating that source code |
| implementing the operations of each class, as methods |
| ensuring that the components provide the same interfaces as the design classes |
This activity involves ensuring that the requirements associated with each subsystem are implemented in the appropriate build by components and/or other subsystems.
implementation (description)
The term implementation refers to a definition of how something is constructed or computed.
A realization relationship relates an implementation to its specification.
implementation (stereotype)
The term implementation also refers to a stereotyped generalization within which the client inherits the supplier's attributes, operations, and methods, but not its interfaces.
implementationClass
The term implementationClass refers to a stereotyped class that provides a static physical implementation of that class. This implementation includes attributes, associations with other classes, and methods.
An implementationClass is usually associated with static classes within a programming langugage.
implementation inheritance
The term implementation inheritance refers to the inheritance of the implementation of a given parent element's structure (attributes, operations, and associations) and code (methods).
The principle of substitutability applies to the inheriting element.
implementation model
An implementation model is a stereotyped model that contains a hierarchy of implementation subsystems.
The implementation model is meant to show how elements of the design model are implemented within the system, in terms of components. This model also describes how those components are organized and the dependencies among them.
Within the RUP, the implementation model is part of the implementation set.
implementation requirements
The term implementation requirements refers to a tagged value whose value contains text describing nonfunctional requirements, associated with either a design class or a use-case realization--design, that are identified and specified during design but are better handled during implementation.
implementation set
Within the RUP, the implementation set is the set of artifacts related to the deliverable system.
The implementation set contains the implementation model.
implementation subsystem
An implementation subsystem is a stereotyped subsystem used to organize components and interfaces within an implementation model.
An implementation subsystem can also contain other implementation subsystems.
implementation system
The term implementation system is a stereotype that refers to the top-level package within the implementation model.
implementation view
The term implementation view refers to the set of components and files that together form the releasable system. This view focuses on configuration management.
The implementation view is captured primarily in component diagrams, and also in interaction diagrams, statechart diagrams, and activity diagrams.
The implementation view is a part of the static view. The implementation view is also one of the five interlocking views that comprise the architecture.
implementation workflow (RUP)
Within the RUP, there are four purposes of the implementation workflow:
| define the organization of the code |
| implement classes and objects within components |
| perform unit testing of those components |
| integrate the components into an executable system |
The following activities comprise the implementation workflow:
| Architectural Implementation |
| Integrate System |
| Implement a Subsystem |
| Implement a Class |
| Perform Unit Test |
Implement Test
Implement Test is the third activity within the test workflow.
This activity involves creating test components.
implicit
The term implicit is a constraint attached to an association to signify that the association is "conceptual," as opposed to actual.
implies
The term implies refers to an OCL operator which states that a given Boolean expression resolves to True if when the first Boolean is True, the second Boolean operand is also True. (If the first operand is False, the expression evaluates to True regardless of the value of the second operand.)
import
The term import is a stereotyped dependency within which the names of the elements in the target package are added to the namespace of the source package.
import interface
An import interface is an interface that a component conforms to and builds on.
inactive
The term inactive applies to a state that is not currently being held by a given object within a state machine.
inception phase
The inception phase is the phase of a development project in which the business case for the proposed system is developed and presented.
The primary goal of this phase is to reach an initial agreement among the stakeholders as to what the new system will accomplish and how much time and money will be required to build it.
include
The term include is a stereotyped dependency within which the source use case explicitly incorporates the behavior of the target use case at a location specified within the source use case.
You generally use an include dependency to put behavior common to several use cases in its own use case.
includes
The term includes refers to an oclOperation that returns True if a specified object is an element of a given Collection.
includesAll
The term includesAll refers to an oclOperation that returns True if all of the elements within a specified Collection are elements of another given Collection.
including
The term including refers to an oclOperation that works on a Collection.
| For a Bag, the including operation adds a given element. |
| For a Set, the operation adds a given element if that element is not already present. |
| For a Sequence, the operation adds a given element at the end. |
increment
An increment is a small and manageable part of the system being built, such as the delta between two successive builds.
An increment is the result of an iteration.
incremental process
An incremental process is a process that involves the continuous integration of a system's architecture to produce executable releases, with each new release containing incremental improvements on its predecessor.
indirect instance
An indirect instance is an entity that is an instance of a given element and also an instance of a child of that element.
inheritance
The term inheritance refers to a mechanism by which more specific elements incorporate structure and behavior defined by more general elements.
initialization
The term initialization refers to the act of setting the value of a newly created object, including the values of its attributes, its links, and its initial state.
initial operational capability
The term initial operational capability refers to the major milestone that concludes the construction phase.
initial state
An initial state is a pseudostate that indicates the default starting place for a transition whose target is the boundary of a composite state.
initial value
A initial value is an expression that specifies the value that a given attribute holds upon initialization.
instance
An instance is a named entity that has its own identity and value. It represents a concrete manifestation of an abstraction.
Examples of instances within the UML include objects (instances of classes) and links (instances of associations).
instanceOf
The term instanceOf refers to a stereotyped dependency that signifies that the source object is an instance of the target classifier.
instantiable
A generalizable element is instantiable if it can have instances.
instantiate
The term instantiate refers to a stereotyped dependency within which the source class creates instances of the target class.
instantiation
The term instantiation refers to a dependency within which the source creates instances of the target.
You model an instantiation using the instantiate stereotype.
Integrate System
Integrate System is the second activity within the implementation workflow.
This activity involves creating an integration build plan and then integrating each build so integration testing can be performed.
integration build plan
An integration build plan describes the sequence of builds required for a given iteration.
integration tester
An integration tester is a worker who performs integration tests.
intent
An intent is the set of behavioral features and structural features associated with a descriptor.
interaction
An interaction is a set of messages exchanged among a set of objects to accomplish a particular purpose within a given context (such as a collaboration).
interaction diagram
An interaction diagram is a diagram that shows an interaction.
There are two kinds of interaction diagrams: collaboration diagrams and sequence diagrams.
interaction view
The term interaction view refers to those aspects of a given model that involve exchanges of messages among objects to accomplish some purposes.
The interaction view is captured in sequence diagrams and/or collaboration diagrams.
The interaction view is a part of the dynamic view.
interface
An interface is a named collection of externally visible operations provided by one or more design classes, design subsystems, components, and/or implementation subsystems.
You can think of an interface as specifying a "contract" for a class or a component without specifying its implementation.
interface inheritance
The term interface inheritance refers to the inheritance of the interface of a given parent element, but not that element's implementation.
interface specifier
An interface specifier is a reference to an interface or a class that specifies the behavior required of a given class within a particular association.
internal transition
An internal transition is a transition that has an associated action but does not result in a change of state.
intersection
The term intersection refers to an oclOperation that combines two Sets, two Bags, or a Bag and a Set into a new Collection.
invariant
The term invariant refers to a stereotyped constraint, attached to an element, which specifies a Boolean expression that must always resolve to True.
isEmpty
The term isEmpty refers to an oclOperation that returns True if a given Collection contains no elements.
iterate
The term iterate refers to an oclOperation that evaluates a specified expression for each element within a given Collection.
iteration
An iteration is a distinct set of activities, based on a plan and specified evaluation criteria, which together form a complete development cycle that results in a release of a partial or complete system.
iteration expression
An iteration expression is an expression that yields a set of iteration cases, each of which specifies an execution of an action within its associated iteration.
iteration plan
An iteration plan is a fine-grained plan for one iteration within a project. This plan plan defines the tasks to be performed within the given iteration in terms of the key dates and the required resources.
iteration workflow
An iteration workflow is a concrete instance of a workflow, from the perspective of what happens in a typical iteration.
iterative process
An iterative process is a process that involves managing a stream of executable releases.
join
A join is a transition with two or more source states and one target state.
junction state
A junction state is a pseudostate that makes it possible to build a single overall transition from a series of transition fragments.
keyword
The term keyword refers to a reserved word in the UML.
The following keywords are predefined:
| actor |
| bind |
| exception |
| interface |
| model |
| refine |
| signal |
| subsystem |
| trace |
| use |
last
The term last refers to an oclOperation that returns the last element in a given Sequence.
layer
A layer is a set of subsystems that share the same degree of generality and interface volatility.
Within a layered architecture, the lower layers tend to be general to several applications, and thus must have relatively stable interfaces, while higher layers tend to be more application-specific and may have less stable interfaces as a result.
leaf
A leaf is a generalizable element that has no children in a given generalization hierarchy.
library
A library is a stereotyped component that represents a static or dynamic object library.
life-cycle architecture
The term life-cycle architecture refers to the major milestone that concludes the elaboration phase.
life-cycle objective
The term life-cycle objectives refers to the major milestone that concludes the inception phase.
lifeline
A lifeline is a vertical dashed line on a sequence diagram that represents the life of a given object.
link
A link is an instance of an association that represents a connection among two or more objects.
link end
A link end is an instance of an association end.
list
A list is an ordered collection, of variable length, of model elements owned by, and nested within, another model element.
local
The term local refers to a stereotype attached to a link end to signify that the corresponding object is visible because it is part of the local scope of the object at the other end of the link.
location
The term location refers to a tagged value whose value specifies the physical placement of a given component on a node.
major milestone
A major milestone is a milestone at the end of a phase that represents a point at which management makes crucial go/no-go decisions, and decisions about schedule, budget, and requirements, for the project.
management set
Within the RUP, the management set is the set of artifacts related to the software business and to the management of a project.
The management set contains the following artifacts:
| business case |
| change requests |
| deployment plan |
| iteration assessment |
| iteration plans |
| software development plan |
| status assessment |
Mealy machine
A Mealy machine is a state machine whose actions are all attached to transitions.
mechanism
A mechanism is a design pattern that applies to a society of classes. It can take the form of a regular collaboration or a parameterized collaboration (in other words, a template).
member
The term member refers to an attribute, an operation, or a method belonging to a classifier.
merge
A merge is a place within a state machine, or on an activity diagram or a sequence diagram, where two or more alternate control paths come together.
message
A message is a conveyance of information from one object to one or more other objects with the expectation that activity will ensue, in the form of an action.
A message can be either a signal or a call.
Within a process or a thread, messages are ordered in sequence by time.
metaclass
The term metaclass refers to a stereotype attached to a classifier to signify that all instances of that classifier are classes.
metarelationship
A metarelationship is a relationship that connects a descriptor to its instances.
method
A method is an implementation of an operation.
middleware layer
The term middleware layer refers to a layer of a system which contains packages and/or subsystems that can be reused for platform-independent services such as object request brokers (ORBs).
minor milestone
A minor milestone is an intermediate milestone between two major milestones, which generally represents the point at which a given iteration ends or when a build is finalized.
minus
The term minus refers to an oclOperation that creates a Set which contains all of the elements that are in one Set but not another.
model
The term model is a keyword that refers to a semantically complete abstraction of a system. It represents a simplification of the reality of that system.
Reasons to build models include the following:
| to communicate the desired structure and behavior of a system |
| to visualize and control the system's architecture |
| to better understand the system and explore opportunities for simplification and reuse |
| to manage risk |
The following models are defined for the Unified Process:
| analysis model |
| deployment model |
| design model |
| implementation model |
| test model |
| use-case model |
model management view
The term model management view refers to those aspects of a given model that involve its structured parts, including packages and subsystems.
The model management view is captured primarily in class diagrams.
module
The term module refers to a unit of software.
Moore machine
A Moore machine is a state machine whose actions are all attached to states.
multicasting
The term multicasting refers to what happens when an object sends a signal to any object in the system that might be listening.
multiobject
A multiobject is a classifier role that denotes a set of objects rather than a single object.
multiple classification
The term multiple classification refers to a type of generalization in which an object may be a direct instance of more than one class.
multiple inheritance
The term multiple inheritance refers to a form of generalization in which an element may have more than one parent.
multiplicity
The term multiplicity refers to a specification of the number of values that can be present with regard to a given element.
| For an association, multiplicity refers to the number of each association end that can be connected to that association via links. |
| For an attribute, multiplicity refers to the number of values that the attribute can assume within its enclosing object. |
| For a class, multiplicity refers to the number of instances that class can have. |
name (operation)
The term name refers to an oclOperation that returns the name of a given model element.
name (string)
The term name also refers to a string that identifies a model element.
There are two kinds of names: simple names and pathnames.
namespace
A namespace is a part of a model in which each name has a unique meaning.
All model elements belong to at least one namespace.
navigability
The navigability of a link or a binary association refers to whether it is navigable.
navigable
A link or an association is navigable if given an object or a class, respectively, at one end, one can easily and directly get to the object(s) or class(es) at the other end.
navigation
The term navigation refers to the traversal of a link or an association.
Unless otherwise specified, navigation is bidirectional.
navigation efficiency
A binary association has navigation efficiency if the average cost of obtaining the set of objects at one end is proportional to the sum of (a) the number of objects in that set and (b) a fixed constant.
Usually, navigability implies navigation efficiency.
new
The term new refers to a stereotype attached to a classifier role or an association role to signify that an instance of the role is created during execution of the given interaction and still exists once that execution is complete.
node
A node is a named physical element of a system, which exists at run time, that represents a computational resource which generally has memory and often has processing capability, and that executes one or more components.
nonfunctional requirement
The term nonfunctional requirement refers to a requirement that does not specifically relate to the new system's functionality.
note
A note is a symbol that displays textual information related to a model element, such as a comment or a constraint.
notEmpty
The term notEmpty refers to an oclOperation that returns True if a given Collection contains at least one element.
object
An object is an instance of a class that encapsulates state and behavior.
object diagram
An object diagram is a diagram that shows a set of objects and the relationships among them at a particular point in time.
You can think of an object digram as being an instance of a class diagram.
object flow
An object flow is a control flow that represents the relationship between an object and the operation, transition, or other object that creates it or uses it.
object flow state
An object flow state is a state that represents the existence of an object of a particular class at some point within a computation.
object lifeline
The term object lifeline is a synonym of lifeline.
object set expression
An object set expression is an expression that resolves to a Set of objects when evaluated at run time.
object type
An object type is a type that defines instances whose values can change.
OCL
OCL is an acronym for Object Constraint Language, which is a text language you can use to construct expressions for navigation, constraints, preconditions, and so forth.
OclAny
The term OclAny refers to the type that serves as the supertype of all types within a given model.
oclAsType
The term oclAsType refers to an oclOperation that changes a given object from its current type to a different type.
oclIsKindOf
The term oclIsKindOf refers to an oclOperation that returns True if the type of a given object is the same as a specified type or any of that type's subtypes.
oclIsTypeOf
The term oclIsTypeOf refers to an oclOperation that returns True if the type of a given object is the same as a specified type.
oclOperation
The term oclOperation refers to a stereotyped operation to be used exclusively within OCL expressions.
Normally, an operation labeled with this stereotype is not implemented.
oclType
The term oclType refers to an oclOperation that returns the OclType of a given object.
OclType
The term OclType refers to the type of which each type represented within a given model is an instance.
operation
An operation is a named specification of a service that can be requested from any of a class's objects to affect behavior in some way or to return a value without affecting behavior.
The following are the primary aspects of an operation:
| concurrency |
| parameter list |
| return type |
| visibility |
There are two other properties that apply to operations.
| You can set the isPolymorphic property to False to indicate that the operation is not overrideable. |
| You can set the isQuery property to yes to indicate that the operation is a query. |
or
The term or refers to a constraint between two associations which signifies that only one of the associations can be instantiated for a given object at one time.
ordered
The term ordered is a constraint attached to an association to signify that the objects at one end are specified in some explicit order.
orthogonal substate
An orthogonal substate is a substate that exists simultaneously with other substates, all of which are currently active, within a composite state.
overlapping
The term overlapping is a constraint attached to a set of generalizations to signify that given multiple inheritance, an object can be an instance of more than one child within the set.
owner scope
The owner scope of a feature indicates whether the feature applies to a single instance of the enclosing classifier (this is called instance scope) or to the classifier as a whole (this is class scope or classifier scope).
package
A package is a named general-purpose mechanism for organizing model elements, including, for instance, classes, use cases, diagrams, and/or other packages, into groups.
A package is purely conceptual: it does not exist at run time.
Each package within a model forms a namespace.
parameter (element)
A parameter is a specification of a variable that can be changed, passed, or returned.
A parameter has the following parts:
| default value |
| direction: in (input parameter, passed by value), out (output parameter), inout (input parameter that may be modified), or return (return value of call) |
| name |
| type |
parameterized element
The term parameterized element is a synonym of template.
parameter list
A parameter list is an ordered list of parameter declarations.
parent
The term parent refers to the more general element within a given generalization relationship.
participates
A model element participates in a relationship.
passive object
A passive object is an object that does not have its own thread of control.
pathname
A pathname is a name that contains the name of the package(s) that contain(s) a given element.
pattern
A pattern is a parameterized collaboration that represents a common solution to a common problem in a given context.
The classifiers, relationships, and behavior associated with the collaboration can be applied via the binding of model elements to the roles of the given pattern.
performance tester
Within the RUP, a performance tester is a worker who conducts performance tests on the system.
Perform Integration Test
Perform Integration Test is the fourth activity within the test workflow.
This activity involves performing the tests which verify that the components interact properly with each other after they have been integrated into a build.
Perform System Test
Perform System Test is the fifth activity within the test workflow.
This activity involves performing the tests which verify that the system functions properly as a whole.
Perform Unit Test
Perform Unit Test is the fifth activity within the implementation workflow.
This activity involves performing specification, or "black-box," testing to verify each unit's observable behavior, and structure, or "white-box," testing to verify that unit's internal implementation.
permission
The term permission refers to a type of dependency that involves the granting of permission to the client to use the contents of the supplier.
There are three types of permission dependencies:
| access |
| friend |
| import |
There are two allowable persistence values: persistent (the element will be preserved) and transient (the element will not be preserved).
persistent object
A persistent object is an object that continues to exist after the thread that created it has ceased to exist.
phase
A phase is the period of time between two major milestones of a development process.
In the context of the UML, there are four phases:
| inception |
| elaboration |
| construction |
| transition |
A phase plan has three elements:
| dates of the major milestones |
| staffing profile (which resources are required for which phases) |
| dates of the minor milestones |
This activity involves describing a testing strategy, estimating the resources that will be required, and scheduling the testing effort.
polymorphic
An operation is polymorphic if its implementation may be supplied by a descendant class.
postcondition
The term postcondition refers to a stereotyped constraint attached to an operation which specifies a Boolean expression that must resolve to True after that operation completes its execution.
powertype (stereotype on dependency)
The term powertype refers to a stereotype attached to a dependency to signify that the target is a powertype of the source.
powertype (stereotype on metaclass)
The term powertype also refers to a stereotype attached to a metaclass to signify that all instances of that metaclass are subclasses of a given class.
@pre
The term @pre refers to an OCL construct that returns the value of an attribute or an association at the start of the execution of a given operation.
You use this term within a postcondition.
precondition
The term precondition refers to a stereotyped constraint attached to an operation which specifies a Boolean expression that must resolve to True when that operation is invoked.
prepend
The term prepend refers to an oclOperation that adds a specified element to the beginning of a given Sequence.
presentation element
A presentation element is a textual or graphical projection of one or more model elements.
primitive type
A primitive type is a predefined basic data type, such as Integer or String.
Prioritize Use Cases
Prioritize Use Cases is the second activity within the requirements workflow. It involves determining which use cases need to be developed in early iterations and which ones can be developed later in the project.
The results of this activity go into the architectural view of the use case model.
private
The term private refers to a visibility that indicates that a given element is not visible outside of its enclosing namespace, even to descendants.
private inheritance
The term private inheritance refers to the inheritance of the implementation of a given parent element's structure (attributes, operations, and associations) and code (methods).
The principle of substitutability does not apply to the inheriting element.
problem domain
The term problem domain refers to a conceptual area within the domain model that involves the problem to be solved by the system being built.
procedure expression
A procedure expression is an expression that resolves to the execution of a procedure that may affect the state of the running system.
process
The term process refers to a stereotyped classifier that signifies an active class representing a "heavyweight" flow of control.
process view
The term process view refers to the set of threads and processes that together form the concurrency and synchronization mechanisms of the given system. This view focuses on issues such as performance, scalability, and throughput.
The process view is captured in class diagrams, object diagrams, interaction diagrams, statechart diagrams, and activity diagrams.
The difference between the process view and the design_view, in terms of these diagrams, is that the process view focuses on active classes and active objects.
The process view is one of the five interlocking views that comprise the architecture.
product
The term product is a synonym of work product.
product release
The term product release refers to the major milestone that concludes the transition phase.
projection
A projection is a mapping from a set of elements to a subset of itself.
project manager
Within the RUP, the project manager is the worker who allocates resources, establishes priorities, coordinates interactions among the customers and the development team, and keeps the project team focused on the goals of the project.
property
The term property refers to a named value that conveys information about a model element.
Within the UML, attributes, tagged values, and associations are all properties.
property list
A property list is a comma-separated list of properties attached to a model element.
protected
The term protected refers to a visibility value which indicates that a given model element is visible outside of its enclosing namespace only to descendants.
Prototype User Interface
Prototype User Interface is the fourth activity within the requirements workflow. It involves building a logical user interface, and then a physical user-interface prototype.
pseudoattribute
A pseudoattribute is a value, related to a class, that behaves like an attribute.
The UML defines two types of pseudoattributes: rolenames and discriminators.
pseudostate
A pseudostate is a vertex within a state machine that has the basic form of a state but does not behave like a full state.
The UML defines four types of pseudostates:
| history state |
| initial state |
| junction state |
| stub state |
qualifier
A qualifier is a slot for one or more attributes, on one end of a binary association, in which the values of those attributes select one or more objects from the entire set of objects at the other end of the association from the "qualified" object.
query
A query is an operation that returns a value without altering the state of the running system.
reactive object
A reactive object is an object whose behavior is best characterized by its responses to events dispatched outside its context.
realization
A realization is a relationship in which one classifier, such as an interface or a use case, specifies a "contract" that another classifier, such as a class or a collaboration, guarantees to carry out.
realize
To realize a model element is to provide an implementation of that element.
receive
An object receives a message from another object.
receiver
A receiver is an object that receives a message from another object.
reception
A reception is a declaration that a classifer is prepared to react to the receipt of a signal.
reference
The term reference refers to a metarelationship between elements at the same level of detail or between elements in different containers.
refine
The term refine is a keyword that signifies a refinement.
refinement
A refinement is a dependency within which the source is at a finer degree of abstraction than the target.
You model a refinement using the refine keyword.
reification
The term reification refers to the act of reifying something.
reify
To reify a model element is to treat it as an object when it normally would not be treated that way.
reject
The term reject refers to an oclOperation that creates a Collection which contains all of the elements in a given Collection for which a specified Boolean expression is False.
relationship
A relationship is a connection between or among model elements.
The UML defines four basic kinds of relationships:
| association |
| dependency |
| generalization |
| realization |
There are two kinds of releases: internal_releases and external_releases.
request
A request is a stimulus that is sent to one or more instances.
Within the UML, a request takes the form of a call or a signal.
requirement
A requirement is a stereotyped comment that states a responsibility or obligation.
requirements reviewer
Within the RUP, a requirements reviewer is a worker who plans and conducts a formal review of the use-case model.
requirements set
Within the RUP, the requirements set is the set of artifacts related to the definition of what the software system to be developed must accomplish from the customer's point of view.
The requirements set contains the following artifacts:
| business object models |
| business use-case models |
| glossarys |
| stakeholders' needs |
| supplementary business specifications |
| supplementary specifications |
| use-case models |
| use-case storyboard |
| user-interface prototype |
| vision document |
The following activities comprise the requirements workflow:
| Find Actors and Use Cases |
| Prioritize Use Cases |
| Detail a Use Case |
| Prototype User Interface |
| Structure the Use-Case Model |
result
The term result refers to an OCL keyword that contains the return value of an oclOperation.
You use this term within a postcondition.
return action
A return action is an action that results in the transfer of control to the caller of an operation.
risk-driven
The term risk-driven refers to a process within which each new release is focused on addressing, and subsequently reducing, the most significant risks to the success of a development project.
role
A role represents the behavior, or "face," of a model element that participates in a given context.
The UML defines two types of roles: those associated with association ends, and collaboration roles.
rolename
A rolename is a name of an association end within a given association.
root
A root is a generalizable element that has no parents in a given generalization hierarchy.
run-to-completion
The term run-to-completion refers to a transition, or an action sequence, that must be completed in its entirety without interruption.
scenario
A scenario is a sequence of actions that illustrates behavior.
scope
The term scope refers to the context that gives meaning to the name of a given feature.
Within the UML, there are two kinds of scope: owner scope and target scope. (When the term scope appears by itself, it refers to owner scope.)
select
The term select refers to an oclOperation which creates a Collection that contains all of the elements in a given Collection for which a specified Boolean expression is True.
self (keyword)
The term self refers to a keyword that refers to the instance of the type that is the context of a given OCL constraint.
self (stereotype)
The term self also refers to a stereotype attached to a link end to signify that the corresponding object is visible because it is the sender of a message to itself.
self-transition
A self-transition is a transition for which the source state and target state are the same, but which results in a change in state, and therefore the execution of the appropriate exit action and entry action.
semantics
The term semantics refers to a tagged value used to provide a formal specification of the meaning and/or behavior of a classifier or an operation.
send (dependency)
The term send refers to a stereotyped dependency within which the source object sends a signal to the target object.
send (operation)
The term send also refers to an operation that creates a signal and sends it to a receiver object.
send action
A send action is an action that sends a signal to an object.
sender
A sender is an object that sends a message to another object.
Sequence
A Sequence is an ordered Collection of elements, each of which may appear more than once.
You end up with a Sequence when you navigate through an ordered association.
You can perform the following operations on a Sequence, in addition to all of the operations that you can perform on a Collection:
| append |
| at |
| first |
| last |
| prepend |
Sequence diagrams and collaboration diagrams are semantically equivalent, which means you can convert one type of diagram to the other without losing any information. However, a sequence diagram has two key features that a collaboration diagram does not: lifelines and foci of control.
sequence number
A sequence number is a piece of text on a collaboration diagram that indicates the relative execution order of the associated message in the interaction being modeled.
sequential_substate
The term sequential substate is a synonym of disjoint substate.
service package
A service package is a stereotyped package used to structure the system being built according to the services it will provide.
A service package is a kind of analysis package. It sits lower in the hierarchy than regular analysis packages.
service subsystem
A service subsystem is a stereotyped subsystem used to structure the system being built according to the services it will provide.
A service subsystem is a kind of design subsystem. It sits lower in the hierarchy than regular design subsystems.
Set
A Set is a Collection of elements, each of which may only appear once.
You end up with a Set when you navigate through one association whose multiplicity is greater than 1.
You can perform the minus and symmetricDifference operations on a Set, in addition to all of the operations you can perform on a Collection.
signal
The term signal is a keyword that refers to a named object that is dispatched asynchronously by one object and received by another object.
The attributes of a signal serve as its parameters.
Signals are most commonly used to model exceptions.
signal event
A signal event is an event that represents an object's reception of a signal.
signature
The signature of a behavioral feature consists of that feature's name and parameters.
simple name
A simple name is a name that stands alone.
simple state
A simple state is a state that has no substates.
simple transition
A simple transition is a transition that has one source state and one target state.
single classification
The term single classification refers to a type of generalization in which each object has exactly one direct class.
single inheritance
The term single inheritance refers to a type of generalization within which an element may have only one parent.
singleton
A singleton is a class that has exactly one instance.
size
The term size refers to an oclOperation that returns the number of elements in a given Collection.
snapshot
A snapshot is the collection of objects, links, and values of a given system at a particular moment in time.
software architecture description
Within the RUP, the software architecture description is the artifact that describes the architectural views of the various models that represent the new system at the end of the elaboration phase.
The software architecture description is part of the design set.
solution domain
The term solution domain refers to a conceptual area within the domain model that involves the solution to the problem being solved by the system being built.
source scope
The term source scope is a synonym of owner scope.
source state
A source state is a state within a state machine from which a transition leaves.
A source state may be either a substate or a composite state as a whole.
specialization
The term specialization refers to producing a more specific description of a model element by adding one or more children.
special requirements
The term special requirements refers to a tagged value whose value contains text describing one or more nonfunctional requirements.
A specification represents a description of what something is or does, as opposed to an implementation, which is a description of how something is constructed or computed. A realization relationship relates a specification to its implementation.
state
A state is a condition or situation in the life of an object, that lasts for some finite amount of time, during which it satisfies some condition, performs some activity, or waits for some event.
A state may have any or all of these:
| deferred events |
| entry actions |
| exit actions |
| internal transitions |
| name |
| substates |
Within a statechart diagram, the emphasis is the flow of control between states.
state machine
A state machine is a specification of a sequence of states that an object or an interaction goes through during its lifetime, in response to events, and also the responses that the given object or interaction makes to those events.
You can define an initial state and/or a final state for a state machine.
state machine view
The term state machine view refers to those aspects of a given system that involve the specification of behavior of individual s over their lifetimes.
The state machine view is comprised of statechart diagrams.
The state machine view is a part of the dynamic view.
static classification
The term static classification refers to a type of generalization relationship in which an object may not change its type or role.
static view
The term static view refers to those aspects of a given model having to do with the kinds of things that exist within the model, their internal structure, and the relationships that exist among those things.
The static view is captured primarily in class diagrams.
The static view is part of the structural view.
stereotype (mechanism)
A stereotype is an extensibility mechanism that allows you to create new kinds of model elements that are derived from existing ones. These new elements have their own special properties (expressed as tagged values), semantics, and notation.
A model element can have at most one stereotype. However, stereotypes can have children. The following stereotypes are predefined within the UML:
The following stereotypes have been defined as extensions of the UML for the Unified Process:
string
A string is a sequence of text characters.
structural feature
A structural feature is a static feature of an element, such as an attribute.
structural thing
Astructural thing is a noun that represents a mostly static conceptual or physical part of a model.
There are seven kinds of structural things:
| active class |
| class |
| collaboration |
| component |
| interface |
| node |
| use case |
Four views comprise the structural view:
| deployment view |
| implementation view |
| static view |
| use case view |
There are three steps involved in this activity:
| identifying and extracting general and shared descriptions of functionality that can be used by more specific use cases in the context of a generalization |
| identifying and extracting additional and optional descriptions of functionality that can be used to extend use cases |
| identifying other relationships among use cases that can be expressed using the include construct |
stubbed transition
A stubbed transition is a notation which indicates that a given transition involves a transfer into a particular composite state, but the details have been suppressed on the statechart diagram.
stub state
A stub state is a pseudostate within a submachine reference state that identifies a state in the referenced submachine.
subclass
A subclass is a child of another class within a generalization relationship.
submachine
A submachine is a state machine that can be invoked as part of one or more other state machines.
submachine reference state
A submachine reference state is a state that references a submachine such that a copy of that submachine is implicitly part of the enclosing state machine where the reference occurs.
subset
The term subset refers to a constraint between two associations which signifies that the set of links for one association is a subset of the set of links for the other association.
substate
A substate is a state that is part of a composite state.
substitutability principle
The substitutability principle states that an instance of a descendant element can be substituted for an instance of one of that element's ancestors with no loss of information or functionality.
subsystem
The term subsystem is a keyword which refers to a package that represents an independent part of the system being modeled.
subtype
A subtype is a type that is a child of another type.
sum
The term sum refers to an oclOperation that returns the sum of all elements within a given Collection of real numbers or integers.
summarization
The term summarization refers to act of filtering, combining, and abstracting the properties of a set of elements onto their container in order to give a higher-level, more abstract view of a system.
superclass
A superclass is a parent of another class within a generalization.
supertype
A supertype is a type that is a parent of another type.
supertypes
The term supertypes refers to an oclOperation that returns the Set of direct supertypes associated with a given model element.
supplementary business specification
Within the RUP, a supplementary business specification contains definitions associated with the business that are not represented within the business use-case model and the business object model.
The supplementary business specification is part of the requirements set.
supplementary requirement
A supplementary requirement is a requirement that cannot be associated with any particular use case.
Supplementary requirements generally involve non-functional issues such as performance and constraints associated with implementation.
supplementary specification
Within the RUP, a supplementary specification contains information about requirements that are not represented within the use-case model.
The supplementary specification is part of the requirements set.
supplier
The term supplier refers to the element within a given dependency that provides one or more services to the client.
survey description
The term survey description refers to a tagged value whose value contains a text description of a use-case model as a whole.
swimlane
A swimlane is a partition on an activity diagram used to organize responsibilities for activities.
symmetricDifference
The term symmetricDifference refers to an oclOperation which creates a Set that contains all of the elements that are in one Set or another, but not both.
synchronous action
A synchronous action is a request that an object makes that includes waiting for a response.
synch state
A synch state is a state that enables synchronization of control between two concurrent regions within a state machine.
system
The term system refers to a stereotyped package that represents the entire system being modeled.
system administrator
Within the RUP, the system administrator is the worker who maintains the hardware and software development environments and performs tasks such as account administration and backup.
system analyst
A system analyst is a worker who leads and coordinates the effort to identify requirements and build the use-case model.
system integrator
A system integrator is a worker who plans the sequence of builds required in an iteration and integrates each build when its parts have been implemented.
system-software layer
The term system-software layer refers to a layer of a system that contains the software for the computing and networking infrastructure (for instance, the operating system and the database management system [DBMS]).
system tester
A system tester is a worker who performs system tests.
table
A table is a stereotyped component that represents a database table.
tagged value
A tagged value is an extensibility mechanism that allows you to create new information about model elements and presentation elements. (Note that this information applies to an element itself, not its instances.)
A tagged value consists of a tag, which is the name of a property, and a value. Tagged values can appear alone or within lists. The following tags are predefined within the UML:
| documentation |
| location |
| persistence |
| semantics |
The following tags have been defined as extensions of the UML for the Unified Process:
| flow of events |
| flow of events--analysis |
| flow of events--design |
| implementation requirements |
| special requirements |
| survey description |
target state
A target state is a state within a state machine that results from the completion of a transition.
A target state may be either a substate or a composite state as a whole.
technical writer
Within the RUP, a technical writer is a worker who produces end-user support material, such as user guides, help text, and release notes.
template (RUP)
Within the RUP, a template is a model or a prototype of part or all of an artifact.
template (UML)
A template is also a descriptor for a model element that has one or more formal parameters.
You create a usable element, such as a class, by doing an explicit or implicit a binding of actual parameters to the template's formal parameters.
| An explicit binding involves the bind stereotype. |
| An implicit binding involves declaring a class whose name provides the binding. |
test case
A test case specifies an element of the system to test (for instance, a use case or a use-case realization), the conditions under which to execute that test, and the expected input(s) and result(s).
test component
A test component is a stereotyped component that automates part or all of one or more test procedures.
test designer
Within the RUP, the test designer is the worker who generates the test plan and the test model, implements the test procedures, and evaluates test coverage, results, and effectiveness.
test evaluation
A test evaluation is an evaluation of the results of testing efforts.
test model
A test model is a stereotyped model that contains test cases, test procedures, and test components.
The test model is meant to describe how executable components in the implementation model will be tested in the context of integration testing and system testing.
Within the RUP, the test model is part of the design set.
test plan
A test plan identifies the strategies to be used, and the necessary resources, to implement and execute testing of the new system.
test procedure
A test procedure specifies how to perform one or more test cases.
test system
The term test system is a stereotype that refers to the top-level package within the test model.
test workflow
Within both the Unified Process and the RUP, the purpose of the test workflow is to verify that the implemented system does what it is supposed to do.
Within the Unified Process, the following activities comprise the test workflow:
| Plan Test |
| Design Test |
| Implement Test |
| Perform Integration Test |
| Perform System Test |
| Evaluate Test |
time
The term time refers to an absolute or relative moment in time.
time event
A time event is an event that occurs when a given time expression is satisfied.
A time expression generally involves either elapsed time (using the term after) or an absolute time (using the term when).
In addition one more actions and a guard condition, a transition has three parts:
time complexity
The term time complexity refers to the minimum, maximum, and/or average time in which an operation is expected to complete.
time expression
A time expression is an expression that resolves to a time value.
timing constraint
A timing constraint is a constraint that involves an absolute or relative value of time.
timing mark
A timing mark is a denotation of the specific time at which a given event or message occurs.
toolsmith
Within the RUP, a toolsmith is a worker who develops tools to support special needs, provide automation of certain tasks, and provide better integration of existing tools.
top-level subsystem
The term top-level subsystem refers to the subsystem that represents the system itself.
trace
The term trace is a keyword which signifies a dependency that represents a conceptual connection among elements contained within different models (and thus, generally, different levels of abstraction).
transient
The term transient refers to a stereotype attached to a classifier role or an association role to signify that an instance of the role is created during execution of a given interaction, but will cease to exist some time before that execution is complete.
transient link
A transient link is a link that exists only fora limited duration (for instance, during the execution of an operation).
transient object
A transient object is an object that exists only during the lifetime of the thread that created it.
transition
A transition is a relationship between two states within which an object in the first state will perform specified actions, and then enter the second state, when a particular event occurs and a given guard condition is satisfied.
| source state |
| target states |
| triggers |
The primary goal of this phase is to reach the point at which the system is recognized as matching the criteria specified by the vision document.
transition time
The term transition time is a synonym of timing mark.
trigger
A trigger is an event whose occurrence makes a transition eligible to fire.
triggerless transition
A triggerless transition is a transition that does not have an explicit trigger.
When a triggerless transition is coming from a normal state, it is a completion transition.
type
The term type is a stereotyped class that specifies a set of objects together with the operations that apply to those objects.
A type may also include attributes and associations; this is the main difference between types and interfaces.
type expression
A type expression is an expression that resolves to a reference to one or more data types.
uninterpreted
The term uninterpreted refers to a type or value whose implementation the UML does not specify.
uninterpreted action
An uninterpreted action is an action whose syntax and evaluation is not defined within the UML.
union
The term union refers to an oclOperation that combines two Sets, two Bags, a Bag and a Set, or two Sequences into a new Collection.
usage
A usage relationship is a dependency within which the target requires the presence of the source for its correct functioning or implementation.
You model a regular usage relationship using the use keyword. There are also several variations, including:
| call |
| instantiation |
| parameter |
| send |
use case
A use case is a named collection of classes, interfaces, and other elements that work together to provide some behavior that is bigger than the behavior represented by the sum of the parts. This behavior yields an observable result of value to one or more actors.
A use case always has one main flow of events (also known as a basic course of action, and will generally have at least one exceptional flow of events (or alternate course of action.
use case diagram
A use case diagram is a diagram that shows a set of use cases and actors and the relationships among them.
use case driven
A process is use case driven if it involves using use cases at the center of the following tasks:
| establishing the desired behavior of the system |
| creating, verifying, and validating the system's architecture |
| testing |
| communicating among project stakeholders |
use case generalization
The term use case generalization refers to a generalization relationship within which the parent and the child are both use cases.
use case instance
A use case instance is an instance of a use case, which represents the execution of the sequence of actions that use case specifies.
use-case model
A use-case model is a stereotyped model that contains use cases and actors and the relationships among them.
The use-case model is meant to describe the complete functionality of the system being built. The idea is that this model lends itself to developers and customers agreeing on the requirements and becomes something of a "contractual agreement."
Within the RUP, the use-case model is part of the requirements set.
use-case realization--analysis
The term use-case realization--analysis refers to a stereotyped collaboration within an analysis model that describes how a given use case is realized and performed, expressed in terms of analysis classes and their associated objects.
A use-case realization--analysis contains four parts:
| text that describes the flow of events of the associated use case |
| one or more class diagrams that show the analysis classes |
| one or more interaction diagrams that show how objects interact to realize the use case |
| any special requirements associated with the use case |
A use-case realization--design contains four parts:
| text that describes the flow of events of the associated use case |
| one or more class diagrams that show the design classes |
| one or more interaction diagrams that show how objects interact to realize the use case |
| any implementation requirements associated with the use case |
use-case system
The term use-case system is a stereotype that refers to the top-level package within the use case model.
use case view
The term use case view refers to the set of use cases that together describe the behavior of a given system as seen by its actors. This view exists to specify the internal and external forces that shape the architecture of the system.
The use case view is captured in use case diagrams, interaction diagrams, statechart diagrams, and activity diagrams.
The use case view is a part of the static view and the dynamic view. The use case view is also one of the five interlocking views that comprise the architecture.
user-interface designer
A user-interface designer is a worker who leads and coordinates the prototyping and design of the user interface for the new system.
user-interface prototype
A user-interface prototype is a prototype whose purpose is to help the development team understand and specify the interactions between human actors and the system being built.
Within the RUP, the user-interface prototype is part of the requirements set.
utility
The term utility refers to a stereotype on a class which indicates that the attributes and operations associated with that class all have class scope. (This means that a utility has no instances.)
value
The term value is a synonym of data value.
value type
A value type is a type that defines instances whose values never change.
vertex
A vertex is a source or a target for a transition within a state machine.
view
A view is a projection of a model.
visibility
The term visibility refers to an enumeration whose values specify the various possibilities that a given feature can be used by a particular classifier.
The three values that visibility may assume are public (this is the default), protected, and private.
vision document
A vision document describes a general vision of the project's requirements, key features, and main constraints from the customer's point of view.
when
The term when is a keyword used in conjunction with a Boolean expression to model a change event.
worker
The term worker refers to a role played by an individual, or a group of individuals working together as a team, on a project.
A worker is responsible for performing certain activities and producing certain artifacts.
workflow
A workflow is a sequence of activities that produces a result of observable value.
The Unified Process contains five "core" workflows:
| analysis workflow |
| design workflow |
| implementation workflow_UP |
| requirements workflow |
| test workflow |
The RUP contains nine "core" workflows:
work unit
A work unit is a set of business entities that has meaning to a customer.
A work unit is also an artifact.
xor
The term xor is a constraint attached to a set of associations, connected to a base class, to signify that the class may participate in only one of the associations.