CushionTheBlow (구 BluemoonSoft)

In the Unified Modeling Language, a deployment diagram serves to model the hardware used in system implementations, the components deployed on the hardware, and the associations between those components. The elements used in deployment diagrams are nodes (shown as a cube), components (shown as a rectangular box, with two rectangles protruding from the left side) and associations.

In UML 2.0 components are not placed in nodes. Instead artifacts and nodes are placed in nodes. An artifact is something like a file, program, library, or data base constructed or modified in a project. These artifacts implement collections of components. The inner nodes indicate execution environments rather than hardware. Examples of execution environments include language interpreters, operating systems, and servlet / EJB containers.

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

In the Unified Modeling Language, a component diagram depicts how a software system is split up into components and shows the dependencies among these components. Physical components include files, headers, link libraries, modules, executables, or packages. Component diagrams are prevalent in the field of software architecture but can be used to model and document any system’s architecture.

Note that components are types and only executable components may have instances.

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

State diagrams are used to graphically represent finite state machines. State transition tables are another possible representation.

There are many forms of state diagrams, which differ slightly and have different semantics.

UML state diagram
The Unified Modeling Language (UML) state diagram is essentially a Harel statechart with standardized notation, which can describe a lot of things, from computer programs to business processes. The following are the basic notational elements that can be used to make up a diagram:

- Filled circle, pointing to the initial state
- Hollow circle containing a smaller filled circle, indicating the final state (if any)
- Rounded rectangle, denoting a state. Top of the rectangle contains a name of the state. Can contain a horizontal line in the middle, below which the activities that are done in that state are indicated
- Arrow, denoting transition. The name of the event (if any) causing this transition labels the arrow body. A guard expression may be added after a "/" and enclosed in square-brackets ( eventName[guardExpression] ), denoting that this expression must be true for the transition to take place. If an action is performed during this transition, it is added to the label following a "/" ( eventName[guardExpression]/action ).
- Thick horizontal line with either x>1 lines entering and 1 line leaving or 1 line entering and x>1 lines leaving. These denote join/fork, respectively.

According to the "UML Pocket Reference By Don Pilone" the only predefined guard condition is ELSE. No other examples are provided within that publication.

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

In the Unified Modeling Language, an activity diagram represents the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control.

Overview
In SysML the activity diagram has been extended to indicate flows among steps that convey physical element (e.g., gasoline) or energy (e.g., torque, pressure). Additional changes allow the diagram to better support continuous behaviors and continuous data flows.

In UML 1.x, an activity diagram is a variation of the UML State diagram in which the "states" represent activities, and the transitions represent the completion of those activities.

The UML 2.0 activity diagram, while similar looking to the UML 1.x activity diagram, has semantics based on Petri nets. In UML 2.0, the interaction overview diagram is based on the activity diagram.

Construction
Activity diagrams are typically used for business process modeling. They consist of:

- Initial node.
- Activity final node.
- Activities

The starting point of the diagram is the initial node, and the activity final node is the ending. An activity diagram can have zero or more activity final nodes. Inbetween activities are represented by rounded rectangles.

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

The Message Sequence Chart technique has been incorporated into the Unified Modeling Language (UML) diagram under the name of Sequence Diagram. A sequence diagram shows, as parallel vertical lines, different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner.

For instance, the UML 1.x diagram on the right describes the sequences of messages of a (simple) Restaurant System. This diagram represents a Patron ordering food and wine, drinking wine then eating the food, and finally paying for the food. The dotted lines extending downwards indicate the timeline, time flows from top to bottom. The arrows represent messages (stimuli) from an actor or object to other objects. For example, the Patron sends message 'pay' to the Cashier. Half arrows indicate asynchronous method calls.

The UML 2.0 Sequence Diagram supports similar notation to the UML 1.x Sequence Diagram with added support for modeling variations to the standard flow of events.

If the lifeline is that of an object, it is underlined (if not it is a role). Note that leaving the instance name blank can represent anonymous and unnamed instances.

In order to display interaction, messages are used. These are horizontal arrows with the message name written above them. Solid arrows with full heads are synchronous calls, solid arrows with stick heads are asynchronous calls and dashed arrows with stick heads are return messages. This definition is true as of UML 2, considerably different from UML 1.x.

Activation boxes, or method-call boxes, are opaque rectangles drawn on top of lifelines to represent that processes are being performed in response to the message.

Objects calling methods on themselves use messages and add new activation boxes on top of any others to indicate a further level of processing.

When an object is destroyed (removed from memory), an X is drawn on top of the lifeline, and the dashed line ceases to be drawn below it (this is not the case in the first example though). It should be the result of a message, either from the object itself, or another.

A message sent from outside the diagram can be represented by a message originating from a filled-in circle.

A UML diagram may perform a series of steps, called a superstep, in response to only one external stimulus.

Usage and limitations
Some systems have simple dynamic behavior that can be expressed in terms of specific sequences of messages between a small, fixed number of objects or processes. In such cases sequence diagrams can completely specify the system's behavior. Often, behavior is more complex, e.g. when the set of communicating objects is large or highly variable, when there are many branch points (e.g. exceptions), when there are complex iterations, or synchronization issues such as resource contention. In such cases, sequence diagrams cannot completely describe the system's behavior, but they can specify typical use cases for the system, small details in its behavior, and simplified overviews of its behavior.

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

A Unified Modeling Language (UML) composite structure diagram shows the internal structure of a class and the collaborations that this structure makes possible. This can include internal parts, ports through which the parts interact with each other or through which instances of the class interact with the parts and with the outside world, and connectors between parts or ports. A composite structure is a set of interconnected elements that collaborate at runtime to achieve some purpose. Each element has some defined role in the collaboration.

Composite structure concepts in the UML 2.0 specification
The key composite structure entities identified in the UML 2.0 specification are structured classifiers, parts, ports, connectors, and collaborations.

Structured classifier
A StructuredClassifier represents a class, often an abstract class, whose behavior can be completely or partially described through interactions between parts. An EncapsulatedClassifier is a type of structured classifier that contains ports. In the diagram, both FibonacciSystem and Variable are encapsulated classifiers because they both have ports along their boundaries.

Part
A part represents a role played at runtime by one instance of a class or by a collection of instances. The part may only name the role, it may name an abstract superclass, or it may name a specific concrete class. The part can include a multiplicity factor, such as the [0..*] shown for Viewer in the diagram.

Port
A port is an interaction point that can be used to connect structured classifiers with their parts and with the environment. Ports can optionally specify the services they provide and the services they require from other parts of the system. In the diagram, each of the small squares is a port. Each port has a type and is labelled with a name, such as "var", "indVar1", or "view" in the diagram. Ports may contain a multiplicity factor, for example.

Ports can either delegate received requests to internal parts, or they can deliver these directly to the behavior of the structured classifier that the port is contained within. Public ports that are visible in the environment are shown straddling the boundary, while protected ports that are not visible in the environment are shown inside the boundary. All the ports in the diagram are private, except for the view port along the right boundary of FibonacciSystem.

Connector
A connector binds two or more entities together, allowing them to interact at runtime. The connector is shown as a line between some combination of parts, ports and structured classifiers. The diagram shows three connectors between ports, and one connector between a structured classifier and a part.

Collaboration
A collaboration is generally more abstract than a structured classifier. It is shown as a dotted oval containing roles that instances can play in the collaboration.

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

This UML 2.0 composite structure diagram specifies that instances of the FibonacciSystem class are composed of a number of parts. The topmost of these parts is identified as having the classifier FibonacciFunction. Three of the parts are identified by the role they play within instances of FibonacciSystem - the NMinus2 role, the NMinus1 role, and the N role. The fifth part, identified by its classifier Viewer, includes a multiplicity specification. At runtime there can be 0 or more instances of Viewer or some concrete subclass of Viewer.

At runtime the class instances that implement these three roles must provide the services specified by the IVar interface through their var ports. One such class is Variable, shown on the diagram with a port named var of type Var that realizes the IVar interface.

The port named "view" is a non-public port that can be used by an instance of FibonacciSystem to access the optional instance(s) of Viewer.

Working with composite structure diagrams
UML 2.0 modeling tools should provide a separate composite structure diagram. The drawing icons are typically labeled Classifier (structured or encapsulated classifier), Part, Port, Connector, and Collaboration.

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

An entity-relationship model is an abstract conceptual representation of structured data. Entity-relationship modeling is a relational schema database modeling method, used in software engineering to produce a type of conceptual data model (or semantic data model) of a system, often a relational database, and its requirements in a top-down fashion. Diagrams created using this process are called entity-relationship diagrams, or ER diagrams for short. Originally proposed in 1976 by Dr. Pin-Shan (Peter) Chen (陳品山), many variants of the process have subsequently been devised.

The first stage of information system design uses these models during the requirements analysis to describe information needs or the type of information that is to be stored in a database. The data modeling technique can be used to describe any ontology (i.e. an overview and classifications of used terms and their relationships) for a certain universe of discourse (i.e. area of interest). In the case of the design of an information system that is based on a database, the conceptual data model is, at a later stage (usually called logical design), mapped to a logical data model, such as the relational model; this in turn is mapped to a physical model during physical design. Note that sometimes, both of these phases are referred to as "physical design".

There are a number of conventions for entity-relationship diagrams (ERDs). The classical notation is described in the remainder of this article, and mainly relates to conceptual modeling. There are a range of notations more typically employed in logical and physical database design, including IDEF1x (ICAM DEFinition Language) and dimensional modeling.

Connection
A sample ER diagramAn entity represents a discrete object. Entities can be thought of as nouns. Examples: a computer, an employee, a song, a mathematical theorem. Entities are represented as rectangles.

A relationship captures how two or more entities are related to one another. Relationships can be thought of as verbs, linking two or more nouns. Examples: an owns relationship between a company and a computer, a supervises relationship between an employee and a department, a performs relationship between an artist and a song, a proved relationship between a mathematician and a theorem. Relationships are represented as diamonds, connected by lines to each of the entities in the relationship.

The model's linguistic aspect described above is utilized in the database query language ERROL.

Entities and relationships can both have attributes. Examples: an employee entity might have a Social Security Number (SSN) attribute; the proved relationship may have a date attribute. Attributes are represented as ellipses connected to their owning entity sets by a line.

Every entity (unless it is a weak entity) must have a minimal set of uniquely identifying attributes, which is called the entity's primary key.

Entity-relationship diagrams don't show single entities or single instances of relations. Rather, they show entity sets and relationship sets. Example: a particular song is an entity. The collection of all songs in a database is an entity set. The eaten relationship between a child and her lunch is a single relationship. The set of all such child-lunch relationships in a database is a relationship set.

Lines are drawn between entity sets and the relationship sets they are involved in. If all entities in an entity set must participate in the relationship set, a thick or double line is drawn. This is called a participation constraint. If each entity of the entity set can participate in at most one relationship in the relationship set, an arrow is drawn from the entity set to the relationship set. This is called a key constraint. To indicate that each entity in the entity set is involved in exactly one relationship, a thick arrow is drawn.

Associative entity is used to solve the problem of two entities with a many-to-many relationship.

Unary Relationships - a unary relationship is a relationship between the rows of a single table.

Reference:
http://en.wikipedia.org/wiki/Entity-relationship_model

In the Unified Modeling Language (UML), a class diagram is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes.

Relationships
A relationship is a general term covering the specific types of logical connections found on class and object diagrams. UML shows the following relationships:

Instance-Level Relationships
Link
A Link is the basic relationship among objects. It is represented as a line connecting two or more object boxes. It can be shown on an object diagram or class diagram. A link is an instance of an association.

Association
An Association represents a family of links. Binary associations (with two ends) are normally represented as a line, with each end connected to a class box. Higher order associations can be drawn with more than two ends. In such cases, the ends are connected to a central diamond.

An association can be named, and the ends of an association can be adorned with role names, ownership indicators, multiplicity, visibility, and other properties. There are five different types of association. Bi-directional and uni-directional associations are the most common ones. For instance, a flight class is associated with a plane class bi-directionally. Associations can only be shown on class diagrams.

Example: "department offers courses", is an association relationship.

Aggregation
Aggregation is a variant of the "has a" or association relationship; aggregation is more specific than association. It is an association that represents a part-whole relationship. As a type of association, an aggregation can be named and have the same adornments that an association can. However, an aggregation may not involve more than two classes.

Aggregation can occur when a class is a collection or container of other classes, but where the contained classes do not have a strong life cycle dependency on the container--essentially, if the container is destroyed, its contents are not.

In UML, it is graphically represented as a clear diamond shape on the containing class end of the tree of lines that connect contained class(es) to the containing class.

Composition
Composition is a stronger variant of the "has a" or association relationship; composition is more specific than aggregation. It is represented with a solid diamond shape.

Composition has a strong life cycle dependency between instances of the container class and instances of the contained class(es): If the container is destroyed, every instance that it contains is destroyed as well.

The UML graphical representation of a composition relationship is a filled diamond shape on the containing class end of the tree of lines that connect contained class(es) to the containing class.

Differences between Composition and Aggregation
The whole of a composition must have a multiplicity of 0..1 or 1, indicating that a part must be for only one whole. The part of an aggregation may have any multiplicity.

When attempting to represent real-world whole-part relationships, e.g., an engine is part of a car, the composition relationship is most appropriate. However, when representing a software or database relationship, e.g., car model engine ENG01 is part of a car model CM01, an aggregation relationship is best, as the engine, ENG01 may be also part of a different car model, CM02. This is often called a "catalog" relationship

Class Level Relationships
Generalization
The Generalization relationship indicates that one of the two related classes (the subtype) is considered to be a specialized form of the other (the supertype) and supertype is considered as Generalization of subtype. In practice, this means that any instance of the subtype is also an instance of the supertype (An exemplary tree of generalisations of this form is found in binomial nomenclature: human beings are a subtype of simian, which are a subtype of mammal, and so on). The relationship is most easily understood by the phrase 'A is a B' (a human is a mammal, a mammal is an animal).

The UML graphical representation of a Generalization is a hollow triangle shape on the supertype end of the line (or tree of lines) that connects it to one or more subtypes.

The generalisation relationship is also known as the inheritance or "is a" relationship.

The supertype in the generalisation relationship is also known as the "parent", superclass, base class, or base type.

The subtype in the generalisation relationship is also known as the "child", subclass, derived class, derived type, inheriting class, or inheriting type.

Note that this relationship bears no resemblance to the biological parent/child relationship: the use of these terms is extremely common, but can be misleading.

Generalization-Specialization relationship

- A is a type of B
- E.g. "an oak is a type of tree", "an automobile is a type of vehicle"

Generalization can only be shown on class diagrams and on Use case diagrams.

Realization
In UML modeling, a realization relationship is a relationship between two model elements, in which one model element (the client) realizes the behavior that the other model element (the supplier) specifies. A realization is displayed in the diagram editor as a dashed line with an unfilled arrowhead towards the supplier.

Realizations can only be shown on class diagrams.

A realization is a relationship between classes, interfaces, components, and packages that connects a client element with a supplier element. A realization relationship between classes and interfaces and between components and interfaces shows that the class realizes the operations offered by the interface.

General Relationship
Dependency
A dependency exists between two defined elements if a change to the definition of one would result in a change to the other. This is indicated by a dashed arrow pointing from the dependent to the independent element. Several named varieties exist. A dependency can be between instances, classes, or both.

Multiplicity
The association relationship indicates that (at least) one of the two related classes makes reference to the other. In contrast with the generalization relationship, this is most easily understood through the phrase 'A has a B' {a mother cat has kittens, kittens have a mother cat}.

The UML representation of an association is a line with an optional arrowhead indicating the role of the object(s) in the relationship, and an optional notation at each end indicating the multiplicity of instances of that entity (the number of objects that participate in the association). Common multiplicities are:

0..1 No instances, or one instance (optional, may)
1 Exactly one instance
0..* or * Zero or more instances
1..* One or more instances (at least one)

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

A use case diagram is a type of behavioral diagram defined by the Unified Modeling Language (UML) created from a Use-case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals—represented as use cases—and any dependencies between those use cases.

While SysML uses the same notation as UML for use cases, system engineers model at the system or systems-of-systems level.

UML Use Case Diagram
OMG's UML standard defines a graphical notation for modeling use cases with diagrams, but no format for describing these use cases. While the graphical notation and descriptions are important, they are documentation of the use case—a purpose that the actor can use the system for—

The true value of a use case lies in two areas:

- The written description of system behavior regarding a business task or requirement. This description focuses on the value provided by the system to external entities such as human users or other systems.
- The position or context of the use case among other use cases. As an organizing mechanism, a set of consistent, coherent use cases promotes a useful picture of system behavior, a common understanding between the customer/owner/user and the development team.

This diagram describes the functionality of a simplistic Restaurant System. Use cases are represented by ovals and the actors are represented by stick figures. The Patron actor can Eat Food, Pay for Food, or Drink Wine. Only the Chef actor can Prepare Food. Note that both the Patron and the Cashier are involved in the Pay for Food use case. The box defines the boundaries of the Restaurant System, i.e., the use cases shown are part of the system being modelled, the actors are not.

Interaction among actors is not shown on the use case diagram. If this interaction is essential to a coherent description of the desired behavior, perhaps the system or use case boundaries should be re-examined. Alternatively, interaction among actors can be part of the assumptions used in the use case.

Actor Generalization
The only relationship allowed between actors is generalization. This is useful in defining overlapping roles between actors. The notation is a solid line ending in a hollow triangle drawn from the specialized to the more general actor.

Use Case Relationships
Three relationships among use cases are supported by the UML standard, which describes graphical notation for these relationships.

Uses
In one form of interaction, a given use case uses another. The first use case often depends on the outcome of the included use case. This is useful for extracting truly common behaviors from multiple use cases into a single description. The notation is a dashed arrow from the including to the included use case, with the label "«include»". This usage resembles a macro expansion where the included use case behavior is placed inline in the base use case behavior. There are no parameters or return values.

Extend
In another form of interaction, a given use case (the extension) may extend another. This relationship indicates that the behavior of the extension use case may be inserted in the extended use case under some conditions. The notation is a dashed arrow from the extension to the extended use case, with the label '«'extend'»'. This can be useful for dealing with special cases (when A extends B, A is a special case of B), or in accommodating new requirements during system maintenance and extension.

To make the points at which extension may occur explicit extension points may be defined in a use case which are listed in a compartment below the use case.

Generalization
In the third form of relationship among use cases, a generalization/specialization relationship exists. A given use case may be a specialized form of an existing use case. The notation is a solid line ending in a hollow triangle drawn from the specialized to the more general use case. This resembles the object-oriented concept of sub-classing, in practice it can be both useful and effective to factor common behaviors, constraints and assumptions to the general use case, describe them once, and deal same as except details in the specialized cases.

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