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.
|