CushionTheBlow (구 BluemoonSoft)

In computability theory, several closely-related terms are used to describe the "computational power" of a computational system (such as an abstract machine or programming language):

Turing completeness — A computational system that can compute every Turing-computable function is called Turing-complete (or Turing-powerful). Alternatively, such a system is one that can simulate a universal Turing machine.
Turing equivalence — A Turing-complete system is called Turing-equivalent if every function it can compute is also Turing-computable; i.e., it computes precisely the same class of functions as do Turing machines. Alternatively, a Turing-equivalent system is one that can simulate, and be simulated by, a universal Turing machine. (All known Turing-complete systems are Turing-equivalent, which adds support to the Church-Turing thesis.)
(Computational) universality — A system is called universal with respect to a class of systems if it can compute every function computable by systems in that class (or can simulate each of those systems). Typically, universality is tacitly with respect to a Turing-complete class of systems. The term weakly universal is sometimes used to distinguish a system (e.g. a cellular automaton) whose universality is achieved only by modifying the standard definition of Turing machine so as to include unbounded input.

Reference:
http://en.wikipedia.org/wiki/Turing_complete

Design by committee is a wry, pejorative term referring to a style of design and its resultant output when a group of entities comes together to produce something (often the design of technological systems or standards), particularly in the presence of poor and incompetent leadership. The defining characteristics of "design by committee" are needless complexity, internal inconsistency, logical flaws, banality, and the lack of a unifying vision. Successful design and style much more relate to intuition and aesthetics than science or politics.

The term is especially common in technical parlance, and legitimates the need and general acceptance of a unique systems architect. Often, when software is designed by a committee, the original motivation, specifications and technical criteria take a backseat and poor choices may be made merely to appease the egos of several individual committee members. Such products and standards end up doing too many things or having parts that fit together poorly (because the entities who produced those parts were unaware of each other's requirements for a good fit).

The term is also common in automotive parlance for poorly designed or unpopular cars.

One maxim is that a camel is a horse designed by committee; this has been attributed to Vogue magazine, July 1958 and also to University of Wisconsin philosophy professor Lester Hunt.

Reference:
http://en.wikipedia.org/wiki/Design_by_committee

Stereotypes are one of three extensibility mechanisms in Unified Modeling Language (UML).

Stereotypes allow designers to extend the vocabulary of the UML in order to create new model elements, derived from existing ones, but that have specific properties that are suitable for a particular problem domain or otherwise specialized usage.

For example, when modelling a network you might need to have symbols for representing routers and hubs. By using stereotyped nodes you can make these things appear as primitive building blocks.

Graphically, a stereotype is rendered as a name enclosed by guillemets and placed above the name of another element. In addition or alternatively it may be indicated by a specific icon. The icon image may even replace the entire UML symbol.

For example, in a class diagram stereotypes can be used to classify method behavior such as «constructor» and «getter».

Despite appearances, «interface» is not a stereotype but a classifier.

One alternative to stereotypes, suggested by Peter Coad in his book Java Modeling in Color with UML: Enterprise Components and Process is the use of colored archetypes. The archetypes indicated by different-colored UML boxes can be used in combination with stereotypes. This added definition of meaning indicates the role that the UML object plays within the larger software system.

Reference:
http://en.wikipedia.org/wiki/Stereotype_%28UML%29

Timing diagrams (UML 2.0) are a specific type of interaction diagram, where the focus is on timing constraints.

Timing diagrams are used to explore the behaviors of objects throughout a given period of time. A timing diagram is a special form of a sequence diagram. The differences between timing diagram and sequence diagram are the axes are reversed so that the time is increased from left to right and the lifelines are shown in separate compartments arranged vertically.

There are two basic flavors of timing diagram: the concise notation, and the robust notation.

Reference:
http://en.wikipedia.org/wiki/UML_Timing_Diagram

In the Unified Modeling Language (UML) 2.0, a communication diagram is a simplified version of the UML 1.x collaboration diagram.

A Communication diagram models the interactions between objects or parts in terms of sequenced messages. Communication diagrams represent a combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic behavior of a system.

However, communication diagrams use the free-form arrangement of objects and links as used in Object diagrams. In order to maintain the ordering of messages in such a free-form diagram, messages are labeled with a chronological number and placed near the link the message is sent over. Reading a communication diagram involves starting at message 1.0, and following the messages from object to object.

Reference:
http://en.wikipedia.org/wiki/Communication_diagram

In the Unified Modeling Language, a package diagram depicts how a system is split up into logical groupings by showing the dependencies among these groupings. As a package is typically thought of as a directory, package diagrams provide a logical hierarchical decomposition of a system.

Packages are usually organized to maximize internal coherence within each package and to minimize external coupling among packages. With these guidelines in place, the packages are good management elements. Each package can be assigned to an individual or team, and the dependencies among them indicate the required development order.

Reference:
http://en.wikipedia.org/wiki/Package_diagram

In the Unified Modeling Language (UML), an object diagram is a diagram that shows a complete or partial view of the structure of a modeled system at a specific time. This snapshot focuses on some particular set of object instances and attributes, and the links between the instances. A correlated set of object diagrams provides insight into how an arbitrary view of a system is expected to evolve over time. Object diagrams are more concrete than class diagrams, and are often used to provide examples, or act as test cases for the class diagrams. Only those aspects of a model that are of current interest need be shown on an object diagram.

Instance specifications
Each object and link on an object diagram is represented by an InstanceSpecification. This can show an object's classifier (e.g. an abstract or concrete class) and instance name, as well as attributes and other structural features using slots. Each slot corresponds to a single attribute or feature, and may include a value for that entity.

The name on an instance specification optionally shows an instance name, a ':' separator, and optionally one or more classifier names separated by commas. The contents of slots, if any, are included below the names, in a separate attribute compartment. A link is shown as a solid line, and represents an instance of an association.

Object diagram example
As an example, consider one possible way of modeling production of the Fibonacci sequence.

In the first UML object diagram on the right, the instance in the leftmost instance specification is named v1, has IndependentVariable as its classifier, plays the NMinus2 role within the FibonacciSystem, and has a slot for the val attribute with a value of 0. The second object is named v2, is of class IndependentVariable, plays the NMinus1 role, and has val = 1. The DependentVariable object is named v3, and plays the N role. The topmost instance, an anonymous instance specification, has FibonacciFunction as its classifier, and may have an instance name, a role, and slots, but these are not shown here. The diagram also includes three named links, shown as lines. Links are instances of an association.

In the second diagram, at a slightly later point in time, the IndependentVariable and DependentVariable objects are the same, but the slots for the val attribute have different values. The role names are not shown here.

In the last object diagram, a still later snapshot, the same three objects are involved. Their slots have different values. The instance and role names are not shown here.

Working with object diagrams
If you are using a UML modeling tool, you will typically draw object diagrams using some other diagram type, such as on a class diagram. An object instance may be called an instance specification or just an instance. A link between instances is generally referred to as a link. Other UML entities, such as an aggregation or composition symbol (a diamond) may also appear on an object diagram.

Reference:
http://en.wikipedia.org/wiki/Object_diagram