Concept: Concurrency and Resource View
This view focuses on the identification of task threads, the allocation of "passive" objects to those threads, and the strategies for scheduling, synchronizing and sharing resources across those threads.
Relationships
Main Description

The concurrency and resource view of the system architecture focuses on the management of resources and the concurrent aspects of system execution.  By concurrent, we mean that objects may execute in parallel rather than sequentially.  We are stating that we neither know nor care about the relative order of execution of actions between threads except where specifically mentioned.  These points of synchronization are often called rendezvous (or meeting point) and are the hard parts of concurrency modeling.  Sharing data and information is a common reason for threads to rendezvous and synchronize.  Another is the need to control and coordinate asynchronously executing system elements.      

The four major activities done in the specification of the concurrency and resource architecture are 1) specify the tasks, 2) specify the resources and how they are to be shared, 3)  specify the scheduling patterns to be used, and 4) specify how the tasks will synchronize when necessary.

In the UML, concurrency units are specified as «active» objects. These objects are special in that they create the OS task thread in which they run, and they have the explicit responsibility to accept asynchronous events and delegate them to their internal parts. The semantic classes from the object analysis model (PIM) are ultimately added to these «active» objects as parts. Thus, these tasks organize and orchestrate the behavior of the semantic classes. Resources are classes or objects that have a finite capacity of some kind. An important aspects of this view is how these resources are safely shared by multiple threads and the synchronization decisions that govern their interaction.

While the UML is fully capable of representing all aspects of concurrency and resource management, the UML Profile for Scheduleability, Performance and Time, an OMG standard (available at http://www.omg.org/), specifies a standard way of capturing various qualities of service related to concurrency, such as priority, periodicity, worst-case execution time, blocking time, deadlines, and so on.

Care must be taken to avoid deadlock - a condition in which expectations can never, in principle, be met. Performance is one of the primary considerations that drive the strategic decisions in this architectural view; performance analysis tools can perform various kinds of analyses to determine the scheduleability (ability of a set of tasks to always meet their deadlines); of these, Rate Monotonic Analysis (RMA) is the most common.

A concurrent thread is represented as an «active» object in the UML. The "passive" or "semantic" objects that do the real work of the system are contained as parts within these «active» objects. Properties (e.g. tags) can be used to specify concurrency-specific values such as priority, periodicity, and worst-case execution time. If desired, the UML Profile for Scheduleability, Performance, and Time specifies a standard set of stereotypes, tags, and constraints for detailed concurrency modeling.  An important view is the so-called Task Diagram, which is simply a class (or structure) diagram which emphasizes the concurrency units, their relations, and their rendezvous-related elements (e.g. semaphores and message queues).