Unified Process Formal Specification

This is the formal specification for the core UML as defined by the OMG.

A given application will typically use at least one – and often more than one – profile from each of these seven layers. The use of Standard Profiles is an important first-step in the emerging development of code generation technologies based on MDA.
The diagram below illustrates the basic flow through the UPESE and the UML architecture artifacts that are produced at each stage.
The Application Framework and Patterns component in the diagram above is illustrated with a notation showing where the DNEAF is utilized in the UPESE framework.
There are two dimensions to system architecture as defined by the UPESE:
  • Viewpoint – the context for addressing a limited set of quality concerns
  • Model level – UML models that capture various levels of design specificity
The different viewpoints allow for separation of concerns and align with those prescribed in ISO standard ISO/IEC 10746-1: Reference Model – Open Distributed Processing (RM-ODP), which is the foundation for the DNEAF. The UPESE framework provides a set of viewpoints as expressed in Table 1 below.
Viewpoint   Expresses   Concern
Enterprise   Relationship of the enterprise resources and the system   Worker activities
Computation   Logical decomposition of the system as a coherent set of UML subsystems that collaborate to provide the system behavior   System functionality is adequate to realize use cases.

System is extendible and maintainable.

Internal reuse

Good cohesion and connectivity
Engineering   Distribution of resources to support functionality   System physical characteristics are adequate to host functionality and meet supplementary requirements.
Information   Data managed by the system   System has sufficient capacity to store data.

System has sufficient throughput to provide timely access to the data.
Process   Threads of control, which carry out the computation elements   System has sufficient partitioning of processing to support concurrency and reliability needs.
Table 1: Common System Architecture Viewpoints
The viewpoints in Table 1 are some of the most common for software-intensive systems. Many system architectures also require additional, domain-specific viewpoints. Examples include safety, security, and mechanical viewpoints.
Viewpoints represent different areas of concern that must be addressed in the system architecture and design. If there are system stakeholders or experts whose concerns are important to the overall architecture, there is likely to be a need for a set of viewpoint artifacts to capture their design decisions.
It is important to build a system architecture team with staff who are competent to look after the various viewpoints. The team might consist of business analysts and users who take primary responsibility for the enterprise viewpoint, software architects who attend to the computation viewpoint, and engineers who concern themselves with the engineering viewpoint, as well as experts on domain-specific viewpoints.
In addition to viewpoints, a system architecture requires different levels of specification. As the architecture is developed, it evolves from a general, abstract specification to a more specific, detailed specification. Following the Rational Unified Process, there are four architectural levels, which are described in Table 2.
Model Level   Expresses
Context   The system and its actors.
Analysis   Initial partitioning of the system to establish the conceptual approach
Design   Realization of the analysis model to hardware, software, and people
Implementation   Realization of the design model into specific configurations
Table 2: Architectural Levels
Through these levels, the design goes from the abstract to the physical. The context model captures all of the external entities (actors) that interact with the system. These actors may be external to the enterprise that deploys the system or may be internal to the enterprise. In both cases, the actors may be workers or other systems. At the analysis level, the partitions do not reflect choices of hardware, software, and people. Instead, they reflect design approaches for dividing up what the system needs to do and how the effort should be distributed. At the design level, the decisions are made as to the sorts of hardware and software components and worker roles that are needed. At the implementation level, specific choices of hardware and software technology are made to implement the design. For example, at the design level, a data server may be specified. At the implementation level, the decision is made to use a specific platform running a specific database application.

System Architecture Diagrams

The system architecture then is captured in a set of diagrams that express the architecture from various viewpoints and levels. As shown in Table 3, there is not a diagram for every viewpoint-level combination. At the implementation level, a single diagram captures the realization of hardware and software components for each system configuration.
Models           Viewpoints        
    Enterprise   Computation   Information   Engineering   Process
Context   UML organization model

System context diagram
  Enterprise object model   Enterprise data model   Enterprise locality (Distribution of enterprise resources)    
Analysis   Thin Analysis Diagram (“Robustness Diagrams”)   Subsystem diagram   System data model   System locality diagram   System Process diagram
Design   Business Worker Survey   Subsystem class model

Software component model
  System data schema   Descriptor node diagram   Detailed process
Implementation   Worker Instructions       Configurations: deployment diagram with software system components        
Table 3: Static System Architecture Views
Almost all of the artifacts specified in Table 3 are standard UML diagrams. For example, in the analysis level of the computational viewpoint, the system is decomposed in UML as subsystems that collaborate to meet user requirements. In RUP SE, subsystems are defined as in The Unified Modeling Language Reference Manual. These subsystems, in turn, are decomposed into either subsystems or classes. The design level of the computational view is the detailed class model.