Concepts: Process View
To provide a basis for understanding the process organization of the system,
an architectural view called the process view is used in the
Analysis & Design discipline. There is only one process view of the system,
which illustrates the process decomposition of the system, including the mapping
of classes and subsystems on to processes and
threads. The process view is
refined during each iteration. As [BOO98]
states: "With UML, the static and dynamic aspects of this view are captured
in the same kinds of diagrams as for the design view - i.e. class diagrams,
interaction diagrams, activity diagrams and statechart diagrams, but with a
focus on the active classes that represent these threads and processes." Of
concern when constructing and using the process view are, for example, issues of
concurrency, response time, deadlock, throughput, fault tolerance, and
scalability.
It is possible to design for concurrency without the use of direct underlying
operating system support - for example using a specially written scheduler or
other run-time support. In such cases, concurrency is simulated at the
application infrastructure level, rather than in the operating system. If
necessary, other stereotypes (in addition to the standard threads and processes)
may be used to make this distinction (to guide implementation). For example, the
Ada programming language contains its own model of concurrency, based on Ada
tasks; the Ada run-time has to provide this, whether or not the operating system
on which it runs has an appropriate equivalent - threads, say - which could be
used to support Ada tasking.
In real-time systems, the
Rational Unified Process recommends the use of Capsules
to represent active classes in the process view. Capsules have strong semantics to simplify the
modeling of concurrency:
- They use asynchronous message-based communication through Ports
using well-defined Protocols.
- They use run-to-completion semantics for message processing.
- They encapsulate passive objects (ensuring that thread interference cannot
occur).
The process view shows the process organization of the
system.
There are four additional views, the Use-Case View (handled
in the Requirements discipline), and the Logical View, Deployment
View, and Implementation View; these views are handled
in the Analysis & Design and Implementation disciplines.
The architectural views are documented in a Software Architecture
Document. You may add different views, such as a security view, to
convey other specific aspects of the software architecture.
So in essence, architectural views can be seen as abstractions or
simplifications of the models built, in which you make important characteristics
more visible by leaving the details aside. The architecture is an important
means for increasing the quality of any model built during system development.
| |
|