M

major milestone

Within the Unified Process, 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.
 

Manage Acceptance Test at Development Site

Within the RUP, Manage Acceptance Test at Development Site is an activity within the Deployment discipline.

This activity involves testing the product at the development site to determine whether it is sufficiently mature for release as the final deliverable or for distribution to beta testers.
 

Manage Acceptance Test at Installation Site

Within the RUP, Manage Acceptance Test at Installation Site is an activity within the Deployment discipline.

This activity involves installing the product at the customer site and overseeing customer testing of it.

Manage Baselines and Releases

Within the RUP, Manage Baselines and Releases is an activity within the Configuration and Change Management discipline.

The purpose of this activity is to create descriptions of all versions of artifacts that make up the product at the time of a given release or at another major milestone.
 

Manage Change Requests

Within the RUP, Manage Change Requests is an activity within the Configuration and Change Management discipline.

The purpose of this activity is to ensure that changes that occur on the project are made in a consistent manner and that the appropriate stakeholders are informed of the state of the product, changes to it, and the impacts of those changes on project costs and schedules.
 

Manage Changing Requirements

Within the RUP, Manage Changing Requirements is an activity within the Requirements discipline.

This activity involves assessing the impact of changing requirements, using a central control authority (such as a change control board) to control changes to requirements, and maintaining agreement with the customer on these changes.

Manage Iteration

Within the RUP, Manage Iteration is an activity within the Project Management discipline.

The purpose of this activity is to acquire the necessary resources to perform an iteration, allocate the work to be done, and assess the results of the iteration.
 

management reviewer

Within the RUP, a management reviewer is a person playing the role of evaluating project planning and project assessment artifacts at major review points during the project's lifecycle.
 

Manage the Scope of the System

Within the RUP, Manage the Scope of the System is an activity within the Requirements discipline.

This activity involves collecting important information from stakeholders as requirements attributes and use these attributes in prioritizing and scoping the requirements on an ongoing basis.

manifest

The term manifest is a stereotype attached to an artifact that signifies that the artifact is a manifestation.
 

manifestation

A manifestation is an abstraction that represents the concrete physical realization of one or more model elements by an artifact.
 

many

The term many refers to the multiplicity 0..*.

mapping

A mapping is a string that specifies a mapping of a thing to a model element or from one model element to another.
 

mapping expression

A mapping expression is an expression that resolves to a mapping.
 

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.

merge node

A merge node is a control node that brings together multiple alternate control flows.
 

message

A message is a named element that defines a specific kind of communication between lifelines within an interaction.

A message is connected to a dispatching execution occurrence. It specifies the sending and receiving event occurrences as well. A message is also of a particular message kind and a particular message sort.

The notation for a message is always an arrow, but the nature of the arrow and the arrowhead varies based on the type of message.

	A synchronous call or signal message appears as a solid line with a solid arrowhead.
	An asynchronous call or signal message appears as a solid line with an open arrowhead.
	A reply message appears as a dashed line with a solid arrowhead.
	An object creation message appears as a dashed line with an open arrowhead.
	A "lost" message has a small black circle next to the arrowhead.

A "found" message has a small black circle next to the start of the arrow.

message end

A message end is a named element that represents what can occur at the end of a message in the context of a given interaction.

There are two kinds of message ends: event occurrences and gates.
 

message kind

The term message kind refers to an enumeration whose values represent the presence of receiving and sending events connected with a message. The values are as follows:

	complete (both the sending event and receiving event are present)
	found (the receiving event is present, but the sending event is not)
	lost (the sending event is present, but the receiving event is not)
	unknown (neither the sending event nor the receiving event is present)

message operator

A message operator is an OCL operator that returns a set of OclMessages that wrap operation calls and/or signals whose formal definitions match a given name and set of argument types.

message sort

The term message sort refers to an enumeration whose values represent the various sorts of communication that a message can convey. The values are as follows:

	asynchCall (asynchronous operation call)
	asynchSignal (asynchronous signal)
	synchCall (synchronous operation call)
	synchSignal (synchronous signal)

message trigger

A message trigger is a specification that an observable event is caused by a either a call or a signal.

There are three kinds of message triggers:

	any trigger
	call trigger
	signal trigger

metaclass

The term metaclass refers to a stereotype attached to a classifier to signify that all instances of that classifier are classes.
 

metaelement

A metaelement is an element of a metamodel.
 

metamodel

The term metamodel is a stereotype attached to a model to signify that the model is an abstraction of another model—in other words, a model of a model.

The UML itself serves as a metamodel for models that represent actual systems being built.
 

metarelationship

A metarelationship is a relationship that connects a descriptor to its instances.
 

method

A method is an implementation of an operation.
 

middleware layer

Within the Unified Process, the term middleware layer refers to a layer of a system that contains packages and/or subsystems that can be reused for platform-independent services such as object request brokers (ORBs).
 

minor milestone

Within the Unified Process, 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 OCL operation that creates a Set that contains all of the elements that are in one Set but not another.
 

model

A model is a semantically complete abstraction of a system. It represents a simplification of the reality of that system.

More specifically, in UML terms, a model is a package that aggregates a number of model elements.

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 element
 A model element is an element that represents an abstraction drawn from the system being modeled.

Every model element has a name that is unique within the namespace that encloses the model element.

modelLibrary

The term modelLibrary is a stereotype attached to a dependency to signify that the client package is using the source package as a library of shared model elements.
 

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 package diagrams.

model property call expression

A model property call expression is an ocl Expression that refers to a property defined for a classifier. The result value is the evaluation of the corresponding property.

There are three types of model call property expressions:

	attribute call expressions
	navigation call expressions
	operation call expressions

module

Within the Unified Process, the term module refers to a unit of software.
 

Monitor and Control Project

Within the RUP, Monitor and Control Project is an activity within the Project Management discipline.

The purpose of this activity is to schedule and assign project work, monitor project status, handle project exceptions and problems, and report project status on an ongoing basis.
 

Monitor and Report Configuration Status

Within the RUP, Monitor and Report Configuration Status is an activity within the Configuration and Change Management discipline.

The purpose of this activity is to ensure that project repositories are safe and have all of the necessary artifacts, and also to report on the state of the configuration.
 

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.
 

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.

Multiplicity can be a single value (expressed as an integer, such as 0, 1, or 12, or as an expression that, when evaluated, results in one value) or a multiplicity element (such as 3..7 or X..X+3). A multiplicity can also include, singly or as part of a range, an asterisk (*), which indicates many (some unspecified value more than 1).
 

multiplicity element

A multiplicity element is a pairing of nonnegative integers, or an integer and * (many), that specifies a multiplicity. This range takes the form lower..upper. (If the multiplicity element appears next to a string, such as the name of an attribute, the element appears within square brackets [].)

---

vyhledat