UML-Modelling

Unified Modeling Language

 The Unified Modeling Language (UML) is a general-purpose, developmental, modeling language in the

field of software engineering that is intended to provide a standard way to visualize the design of a system.
 The creation of UML was originally motivated by the desire to standardize the disparate notational systems
and approaches to software design.
 It was developed at Rational Software in 1994–1995, with further development led by them through 1996.
 In 1997, UML was adopted as a standard by the Object Management Group (OMG), and has been managed
by this organization ever since.
 In 2005, UML was also published by the International Organization for Standardization (ISO) as an
approved ISO standard. Since then the standard has been periodically revised to cover the latest revision of
UML. 
 In software engineering, most practitioners do not use UML, but instead produce informal hand drawn
diagrams; these diagrams, however, often include elements from UML.
Design

 UML offers a way to visualize a system's architectural blueprints in a diagram, including

elements such as:
 any activities (jobs);
 individual components of the system;
 and how they can interact with other software components;
 how the system will run;
 how entities interact with others (components and interfaces);
 external user interface.
 Although originally intended for object-oriented design documentation, UML has been extended
to a larger set of design documentation, and been found useful in many contexts.
 Cont.
Software development methods
 UML is not a development 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 method, Objectory and especially RUP that it was originally intended to be
used with when work began at Rational Software.
Modeling
 It is important to distinguish between the UML model and the set of diagrams of a system. A diagram is a partial graphic representation of
a system's model. The set of diagrams need not completely cover the model and deleting a diagram does not change the model. The model
may also contain documentation that drives the model elements and diagrams (such as written use cases).
 UML diagrams represent two different views of a system model:
 Static (or structural) view: emphasizes the static structure of the system using objects, attributes, operations and relationships.
It includes class diagrams and composite structure diagrams.
 Dynamic (or behavioral) view: emphasizes the dynamic behavior of the system by showing collaborations among objects and
changes to the internal states of objects. This view includes sequence diagrams, activity diagrams and state machine diagrams.
 UML models can be exchanged among UML tools by using the XML Metadata Interchange (XMI) format.
 In UML, one of the key tools for behavior modeling is the use-case model, caused by OOSE. Use cases are a way of specifying required
usages of a system. Typically, they are used to capture the requirements of a system, that is, what a system is supposed to do.
 Diagrams

 UML has many types of diagrams, which are

divided into two categories. 
 Some types represent structural information,
and the rest represent general types
of behavior, including a few that represent
different aspects of interactions.
 These diagrams can be categorized
hierarchically as shown in the following
class diagram:
 Structure Diagrams

 Structure diagrams represent the static aspects of the system.

 It emphasizes the things that must be present in the system being modeled.
 Since structure diagrams represent the structure, they are used extensively in documenting the software
architecture of software systems.
 F or example, the component diagram describes how a software system is split up into components and shows the
dependencies among these components.
Behavior Diagrams

 Behavior diagrams represent the dynamic aspect of the system.

 It emphasizes what must happen in the system being modeled.
 Since behavior diagrams illustrate the behavior of a system, they are used
extensively to describe the functionality of software systems.
 As an example, the activity diagram describes the business and operational step-
by-step activities of the components in a system.
Interaction Diagrams

 Interaction diagrams, a subset of behavior diagrams, emphasize the flow of

control and data among the things in the system being modeled. e.g., the 
sequence diagram shows how objects communicate with each other regarding a
sequence of messages.
Metamodeling

 The Object Management Group (OMG) has developed a metamodeling architecture to define the
UML, called the Meta-Object F acility (MOF. ).
 MOF is designed as a four-layered architecture, as shown in the image at right. It provides a
meta-meta model at the top, called the M3 layer. This M3-model is the language used by Meta-
Object F acility to build metamodels, called M2-models.
 The most prominent example of a Layer 2 Meta-Object F acility model is the UML metamodel,
which describes the UML itself. These M2-models describe elements of the M1-layer, and thus
M1-models. These would be, for example, models written in UML. The last layer is the M0-layer
or data layer. It is used to describe runtime instances of the system.
 The meta-model can be extended using a mechanism called stereotyping. This has been criticized
as being insufficient/untenable by Brian H enderson-Sellers and Cesar Gonzalez-Perez in “ Uses
and Abuses of the Stereotype Mechanism in UML 1.x and 2.0".