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.

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