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
Schedulability, 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 schedulability (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 Schedulability, 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).
|