Unified Modeling Language

From Wikipedia, the free encyclopedia

Jump to: navigation, search

In the field of software engineering, the Unified Modeling Language (UML) is a non-proprietary specification language for object modeling. UML is a general-purpose
modeling language that includes a standardized graphical notation used to create an abstract model of a system, referred to as a UML model. UML is extendable,
offering the following mechanisms for customization: profiles and stereotype. The semantics of extension by profiles has been improved with the UML 2.0 major
revision.

UML is officially defined at the Object Management Group (OMG) by the UML metamodel – a Meta-Object Facility metamodel (MOF). Like other MOF-based
specifications, the UML metamodel and UML models may be serialized in XMI. While UML was designed to specify, visualize, construct, and document software-
intensive systems, UML is not restricted to modeling software. UML is also used for business process modeling, systems engineering modeling, and representing
organizational structures. The Systems Modeling Language (SysML) is a Domain-Specific Modeling language for systems engineering that is defined as a UML 2.0
profile.

UML has been a catalyst for the evolution of model-driven technologies, which include Model Driven Development (MDD), Model Driven Engineering (MDE), and
model-driven architecture. By establishing an industry consensus on a graphic notation to represent common concepts like classes, components, generalization,
aggregation, and behaviors, UML has allowed software developers to concentrate more on design and architecture.

UML models may be automatically transformed to other representations (e.g. Java) by means of QVT-like transformation languages, supported by the OMG.

Contents

[hide]

• 1 History
• 2 Methods
• 3 Modeling
• 4 Diagrams
• 5 Concepts
• 6 Criticisms
• 7 Extensions
• 8 See also
• 9 Notes
• 10 References

• 11 External links
 [edit] History

After Rational Software Corporation hired James Rumbaugh from General Electric in 1994, the company became the source for the two most popular object-oriented
modeling approaches of the day: Rumbaugh's OMT, which was better for object-oriented analysis (OOA), and Grady Booch's Booch method, which was better for
object-oriented design (OOD). Together Rumbaugh and Booch attempted to reconcile their two approaches and started work on a Unified Method.

They were soon assisted in their efforts by Ivar Jacobson, the creator of the OOSE method. Jacobson joined Rational in 1995, after his company, Objectory, was
acquired by Rational. The three methodologists were collectively referred to as the Three Amigos, since they were well known to argue frequently with each other
regarding methodological preferences.

In 1996 the Three Amigos decided that a Unified Modeling Language was more viable than a Unified Method, and redirected their efforts to respond to the OMG
Request for Proposal (RFP) for an object modeling language ("Object Analysis & Design RFP-1",OMG document ad/96-05-01), which was issued in June 1996.[1]

Under the technical leadership of the Three Amigos, an international consortium called the UML Partners was organized in 1996 to complete the Unified Modeling
Language (UML) specification, and propose it as a response to the OMG RFP. The UML Partners' UML 1.0 specification draft was proposed to the OMG in January
1997. During the same month the UML Partners formed a Semantics Task Force, chaired by Cris Kobryn and administered by Ed Eykholt, to finalize the semantics of
the specification and integrate it with other standardization efforts. The result of this work, UML 1.1, was submitted to the OMG in August 1997 and adopted by the
OMG in November 1997.[2]

As a modeling notation, the influence of the OMT notation dominates (e.g., using rectangles for classes and objects). Though the Booch "cloud" notation was dropped,
the Booch capability to specify lower-level design detail was embraced. The use case notation from Objectory and the component notation from Booch were integrated
with the rest of the notation, but the semantic integration was relatively weak in UML 1.1, and was not really fixed until the UML 2.0 major revision.

Concepts from many other OO methods were also loosely integrated with UML with the intent that UML would support all OO methods. For example CRC Cards (circa
1989 from Kent Beck and Ward Cunningham), and OORam were retained. UML is useful in a variety of engineering problems, from single process, single user
applications to concurrent, distributed systems, making UML rich but large.

It is now an international standard:

ISO/IEC 19501:2005 Information technology -- Open Distributed Processing -- Unified Modeling Language (UML) Version 1.4.2

UML has matured significantly since UML 1.1. Several minor revisions (UML 1.3, 1.4, and 1.5) fixed shortcomings and bugs with the first version of UML, followed
by the UML 2.0 major revision, which is the current OMG standard.

The first part of UML 2.0, the Superstructure which describes the new diagrams and modeling elements available, was adopted by the OMG in October 2004. Other
parts of UML 2, notably the infrastructure, the object constraint language (OCL) and the diagram interchange were yet to be completed and ratified as of November
2005.

The final UML 2.0 specification has been declared available and has been added to OMG's formal specification library. The other parts of the UML specification, the
UML 2.0 infrastructure, the UML 2.0 Diagram Interchange, and UML 2.0 OCL specifications have been adopted but are not yet considered available.
As change is inevitable, a UML 2.1 revision has been underway for some time now. The outcome of this work should be available soon (first semester 2006) in the form
of an XMI 2.1 version of the UML 2.1 version. The corresponding XMI 2.1 file will be made available from the OMG ADTF group.

Most of the commercially successful UML tools now support most of UML 2.0, leaving only the rarely used features left to implement. Of course, it will take some time
for the tools that are in the hands of the developers to reach this level of compliance.

[edit] Methods

UML is not a method by itself; however, it was designed to be compatible with the leading object-oriented software development methods of its time (for example OMT,
Booch, Objectory). Since UML has evolved, some of these methods have been recast to take advantage of the new notation (for example OMT), and new methods have
been created based on UML. Most well known is Rational Unified Process (RUP). There are many other UML-based methods like Abstraction Method, Dynamic
Systems Development Method, and others, designed to provide more specific solutions, or achieve different objectives.

[edit] Modeling

It is important to distinguish between the UML model and the set of diagrams of a system. A diagram is a partial graphical representation of a system's model. The
model also contains a "semantic backplane" — textual documentation such as written use cases that drive the model elements and diagrams.

There are three prominent parts of a system's model:

Functional Model

Showcases the functionality of the system from the user's Point of View.
Includes Use case diagrams.

Object Model

Showcases the structure and substructure of the system using objects, attributes, operations, and associations.
Includes Class Diagrams.

Dynamic Model

Showcases the internal behavior of the system.

Includes Sequence Diagrams, Activity Diagrams and State Machine Diagrams.

Models can be exchanged among UML tools by using the XMI format.

[edit] Diagrams
Hierarchy of UML 2.0 Diagrams, shown as a class diagram

In UML 2.0 there are 13 types of diagrams. To understand them, it is sometimes useful to categorize them hierarchically, as shown in the hierarchy chart on the right.

Structure Diagrams emphasize what things must be in the system being modeled:

• Class diagram
• Component diagram
• Composite structure diagram
• Deployment diagram
• Object diagram
• Package diagram

Behavior Diagrams emphasize what must happen in the system being modeled:

• Activity diagram
• State Machine diagram
• Use case diagram

Interaction Diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:

• Communication diagram
• Interaction overview diagram (UML 2.0)
• Sequence diagram
• UML Timing Diagram (UML 2.0)

The Protocol State Machine is a sub-variant of the State Machine. It may be used to model network communication protocols.

UML does not restrict UML element types to a certain diagram type. In general, every UML element may appear on almost all types of diagrams. This flexibility has
been partially restricted in UML 2.0.
Diagrams can be exchanged among UML tools by using XMI (also DI, XMI[DI]).

In keeping with the tradition of engineering drawings, a comment or note explaining usage, constraint, or intent is always allowed in a UML diagram.

[edit] Concepts

UML uses the following concepts:

For Structure

Actor, Attribute, Class, Component, Interface, Object, Package.

For Behavior

Activity, Event, Message, Method, Operation, State, Use Case.

For Relationships

Aggregation, Association, Composition, Depends, Generalization (or Inheritance).

Other Concepts

• Stereotype. It qualifies the symbol it is attached to.

• Multiplicity notation which corresponds to Database modeling cardinality, e.g., 1, 0..1, 1..*
• Role

Use case diagram

From Wikipedia, the free encyclopedia

Jump to: navigation, search

This article or section may require cleanup to meet Wikipedia's quality standards.
Please help improve this article or replace this tag with a more specific message. This article has been tagged since November 2006. (help, talk)

In the Unified Modeling Language, a use case diagram is a sub class of behavioral diagrams.

The UML defines a graphical notation for representing use cases called the Use case model. UML does not define standards for the written format to describe use cases,
and thus many people have the misapprehension that this graphical notation defines the nature of a use case; however, a graphical notation can only give the simplest
overview of a use case or set of use cases. Use case diagrams are often confused with use cases. While the two concepts are related, use cases are far more detailed than
use case diagrams.

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

Contents

[hide]

• 1 UML Use Case diagram

o 1.1 Use Case Relationships
 1.1.1 Include
 1.1.2 Extend
 1.1.3 Generalization

• 2 External links

[edit] UML Use Case diagram

OMG's UML standard defines a graphical notation for diagramming use cases, but no format for describing use cases. Many people suffer under the misapprehension
that a use case is its graphical notation (or is its description). 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.

It is common practice to create supplementary specifications to capture requirement details that lie outside the scope of use case descriptions. Examples of these topics
include performance, scale/management issues, or standards compliance.
The diagram on the right 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. However, note that actors are a
form of role, a given human user or other external entity may play several roles. Thus the Chef and the Cashier may actually be the same person.

[edit] Use Case Relationships

Three major relationships among use cases are supported by the UML standard, which describes graphical notation for these relationships.
[edit] Include

In one form of interaction, a given use case may "include" 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.

[edit] 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, or in accommodating new requirements during system maintenance and extension.

[edit] 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
with same as except details in the specialized cases.

Class diagram

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Hierarchy of UML 2.0 Diagrams, shown as a class diagram

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.
Contents

[hide]

• 1 Classes
• 2 Relationships
o 2.1 Instance-Level Relationships
 2.1.1 Link
 2.1.2 Association
 2.1.3 Aggregation
 2.1.4 Composition
 2.1.5 Differences between Composition and Aggregation
o 2.2 Class Level Relationships
 2.2.1 Generalization
 2.2.2 Realization
o 2.3 General Relationship
 2.3.1 Dependency (UML)
o 2.4 Multiplicity

• 3 External links

[edit] Classes

A class in the software system is represented by a box with the name of the class written inside it. Classes may also be used to represent domain or other non-software
elements.

An optional compartment below the class name can show the class's attributes (i.e., its properties). Each attribute is shown with at least its name, and optionally with its
type, initial value, and other properties.

The class's operations (indicating the methods) can appear in another compartment. Each operation is shown with at least its name, and optionally also with its
parameters and return type.

Other compartments may be defined, e.g., to capture responsibilities, requirements, constraints.

Attributes and operations may have their visibility marked as follows:

• "+" for public

• "#" for protected
 • "−" for private
• "~" for package

[edit] 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:

[edit] Instance-Level Relationships

[edit] 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.

[edit] Association

An association represents a family of links. Binary associations (with two ends) are normally represented as a line, which 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.

Associations can only be shown on class diagrams.

[edit] Aggregation

Class diagram showing Aggregation between two classes

Aggregation is a variant of the "has a" or association relationship; composition is more specific than aggregation. 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.
[edit] Composition

Composition is a stronger variant of the "has a" or association relationship; composition is more specific than aggregation.

Composition indicates a strong life cycle dependency between instances of the container class and instances of the contained class(es): If the container is destroyed, any
containees are also destroyed.

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

[edit] 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 whole 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.

When attempting to represent software constructs, objects that may only be part of one container at a time, are usually connected by the composition relationship.

[edit] Class Level Relationships

[edit] Generalization

Class diagram showing generalization between one superclass and two subclasses

The generalization relationship indicates that one of the two related classes (the supertype) is considered to be a more general form of the other (the subtype). In practice,
this means that any instance of the subtype is also an instance of the supertype (An exemplary tree of generalizations 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 generalization relationship is also known as the inheritance or "is a" relationship.

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

The subtype in the generalization 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", "a lorry is a type of vehicle"

Generalizations can only be shown on class diagrams.

[edit] 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

Realizations can only be shown on class diagrams.

[edit] General Relationship

[edit] Dependency (UML)

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.

Dependencies can be shown on object diagrams and class diagrams.

[edit] 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

1 Exactly one instance

0..* or
Zero or more instances
*

1..* One or more instances

The association relationship is also known as the "has a" relationship.

Sequence diagram

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Example of a UML 2 diagram
The well-known 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.

[edit] Parts of a Sequence Diagram

A sequence diagram generally shows the interaction between objects over the progression of time. Thus, the first 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

[edit] 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 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.