|
Aurenav UPESE
Unified Process for Enterprise Solution Engineering (UPESE)
The UPESE framework provides a Use-Case and architecture driven agile methodology for both program and project based IT solutions. The UPESE combines the Unified Process with Systems Engineering and Program and Project Management methodologies. UPESE is based around the Rational Unified Process (RUP), the Rational Systems Engineering (SE) plug-in for RUP, and a management extension based on both the PMI and PRINCE2 methodologies (Aurenav has developed several management configurations for the UPESE for use with MS Visio 2003 or later, Rational XDE, Rational Rose Enterprise, Rational Software Architect, Rational SoDA, and Sparx Systems Enterprise Architect that support the ICCP PPM framework, the PMI framework, or the OGC Program and PRINCE2 Project frameworks).
The UPESE supports both business and system use-cases and includes support for subsystem use-cases as illustrated in the model above. The UPESE metamodel also supports any other types of use-case (e.g. Essential Use-Cases, Usage-Centered Use-Cases, etc.).
The UPESE is based on UML 2.x and supports MDA UML Profiles as illustrated in the diagram above. The diagram below illustrates the basic flow through the UPESE and the UML architecture artifacts that are produced at each stage.
The red circle in the diagram above illustrates 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 |
|
|
Levels |
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.
Return to Aurenav Products page.
|
