Overview
The facilities provides by HOPEX IT Architecture V2 for UML modeling are described below.
Analyzing use cases 
Before designing a system, there must be a careful analysis of the functions expected of it. The system components will be used by the “actors” in the organization to perform their tasks. The various “use cases” for the system will be presented in use case diagrams.
These are used as the starting point for discovering objects.
They then allow validation of the use of these objects in the interaction diagrams.
Then they provide criteria for grouping the discovered objects into "packages".
Identifying objects 
Objects with a similar structure, the same behavior, and the same types of relations with other objects, are placed in the same class.
The class diagram identifies the objects involved within the system and defines their structure in terms of attributes and operations, as well as the relationships between them. The object diagram shows the instances compatible with a particular class diagram, and can be used as an example to verify it.
Describing behaviors 
The state machine diagram enables definition of the behavior of an object in response to internal or external requests it may receive. It indicates each possible object state, and the reaction of the object to a given event when in that state.
The activity diagram also describes a behavior, but in terms of actions.
See:
Representing interactions between objects 
The resulting dialog that is initiated between the different objects concerned by the event can be represented in interaction diagrams.
Interaction diagrams emphasize the exchanges that take place between objects.
The sequence diagram shows the same exchanges, but indicates the chronology.
The communication diagram highlights structural organization of objects that send and receive messages.
The interaction overview diagram provides a general view of control flow.
Dividing classes between packages 
Once the objects are identified, it is easy to divide the classes that implement them into different packages. These classes are grouped in the package diagram so as to minimize exchanges between different packages. They meet two criteria: the first is more technical and concerns the execution environment, while the other is more structural and is related to the use it will be put to by the users for each use case.
Defining interfaces 
To respect the principle of encapsulation, there is strict distribution of elements between components. This means interfaces must be provided between elements that have relationships but belong to different components.
The component diagram and the composite structure diagram present the interdependence between components or component elements.
Defining object interfaces while complying with a standard exchange protocol (CORBA2, DCOM/OLE) is key to interoperability, enabling objects developed and used in heterogeneous environments to work together.
See:
Specifying deployment 
Implementation of objects in an concrete working environment can be specified in the deployment diagram.