Practitioner Guides
Practitioner Guides provide practical, task-oriented guidance for applying the Unified Architecture Process (UAP) to software architecture design. The page is organized according to the major UAP activities, from A1 Requirements Refinement through A6 Architecture Evaluation. Each activity is presented with a brief description, followed by its constituent steps and detailed tasks.
Within each activity, the listed step names serve as navigation links to the corresponding detailed guidance. Selecting a step moves directly to that section. This structure allows practitioners either to follow the UAP activities sequentially or to move directly to a specific activity or step needed for their current architecture work.
A1 — Requirements Refinement
Refine requirements so they are sufficiently clear, complete, and architecturally relevant for subsequent architecture design activities.
Step 1. Identify Stakeholders
Identify the stakeholders of the target system so that relevant concerns, expectations, and requirements can be incorporated into architectural decisions.
Task 1. Locate Stakeholder Groups
Identify the key stakeholder groups that should participate in providing concerns, requirements, and other relevant information.
Task 2. Create Stakeholder Profiles
Identify representative individuals within each stakeholder group and record basic profile information such as identification, contact information, and availability.
Step 2. Refine Functional Requirements
Refine the system’s functional requirements by applying requirements engineering principles and techniques.
Task 1. Identify Deficiencies in Functional Requirements
Identify gaps, ambiguities, inconsistencies, and other weaknesses by reviewing each functional requirement in the initial SRS.
Task 2. Resolve Deficiencies in Functional Requirements
Resolve the identified deficiencies by clarifying ambiguities with stakeholders, gathering additional information, and refining the functional requirements accordingly.
Step 3. Refine Non-Functional Requirements
Refine the non-functional requirements of the system by applying requirements engineering principles and techniques.
Task 1. Acquire Architectural Concerns
Gather architectural concerns from stakeholders and derive corresponding non-functional requirements (NFRs) based on those concerns.
Task 2. Identify Deficiencies in Non-Functional Requirements
Identify shortcomings in the NFRs by reviewing each requirement in the initial Software Requirements Specification (SRS).
Task 3. Resolve Deficiencies in Non-Functional Requirements
Resolve identified NFR deficiencies by analyzing each issue, consulting stakeholders for clarification, and revising the requirements accordingly.
A2 — System Context Analysis
Develop a context model for the system by analyzing the refined requirements. The context model represents a high-level abstraction of the system’s boundaries, functionality, datasets, and behavior.
Step 1. Analyze Boundary Context
Step 2. Analyze Functional Context
Step 1. Analyze Boundary Context
Analyze the boundary context of the target system and represent it using a Data Flow Diagram (DFD).
Task 1. Represent System Tiers as Processes
Identify the system tiers of the target system and represent them as processes. In a Level 0 DFD, each process represents a physical system tier, which may correspond to the entire computer system or a specific subsystem.
Task 2. Represent Boundary Elements as Terminals
Model the boundary elements of the system and represent them as terminals. A terminal represents a boundary element that interacts with the system by providing input or receiving output.
Task 3. Represent Persistent Data as Data Stores
Identify the persistent datasets managed by the target system and represent them as data stores.
Task 4. Represent Information Flows as Data Flows
Identify the data flows among processes, terminals, and data stores within the context of the system.
Step 2. Analyze Functional Context
Analyze the functional context of the target system and represent it using a use case diagram.
Task 1. Define Actors
Identify the actors that interact with the target system, where each actor represents a distinct role assumed by an entity engaging with the system.
Task 2. Define Use Cases
Analyze the system’s functionality and represent it through use cases, each capturing a specific and cohesive functional behavior.
Task 3. Define Relationships
Define the relationships depicted in the use case diagram, including those between actors, between actors and use cases, and among use cases.
Step 3. Analyze Information Context
Analyze the informational context of the target system and represent it using a class diagram.
Task 1. Define Persistent Data as Classes
Identify the persistent datasets managed by the system and represent them as persistent object classes.
Task 2. Define Relationships between Classes
Establish relationships among the identified classes using the five standard relationship types in a class diagram: Dependency, Association, Aggregation, Composition, and Inheritance.
Task 3. Define Cardinality on Relationships
Specify the cardinalities of relationships, indicating the number of instances of one class that can be associated with instances of another class.
Step 4. Analyze Behavior Context
Analyze the behavioral context of the target system and represent it using an activity diagram.
Task 1. Allocate Functional Groups onto Tiers
Assign the functional groups of the system across multiple tiers so that each tier is responsible for specific aspects of the system’s overall functionality.
Task 2. Define Invocation Patterns
Identify the most appropriate invocation patterns for each functional group within its designated tier.
Task 3. Define Context-level System Control Flow
Establish the context-level control flow of the system by creating an activity diagram for each tier, utilizing the invocation patterns associated with the functional groups.
A3 — Schematic Architecture Design
Design the schematic architecture of the target system by integrating appropriate architecture styles. The schematic architecture represents the system’s stable and enduring structural layout and serves as the foundation for subsequent architectural decisions.
Step 1. Identify Candidate Architecture Styles
Step 2. Evaluate Candidate Architecture Styles
Step 1. Identify Candidate Architecture Styles
Identify architecture styles suitable for designing the schematic architecture.
Task 1. Observe Structural Characteristics
Identify the structural properties and constraints of the target system that are relevant to informing its architectural design.
Task 2. Determine Inherent Types of the System
Identify the inherent types of the target system in order to narrow down and guide the selection of appropriate architecture styles.
Task 3. Determine Candidate Architecture Styles
Identify the most suitable architecture styles based on the system’s inherent types and structural characteristics.
Step 2. Evaluate Candidate Architecture Styles
Evaluate candidate architecture styles to determine their suitability for the target system.
Task 1. Evaluate Applicable Situations
Assess whether the target system aligns with the applicable conditions and assumptions defined for each candidate architecture style.
Task 2. Evaluate Benefits
Evaluate the extent to which the target system can leverage the benefits offered by each candidate architecture style.
Task 3. Evaluate Drawbacks
Analyze whether the target system can effectively manage or mitigate the potential drawbacks associated with each candidate architecture style.
Task 4. Determine Applicability
Determine the overall suitability of each candidate architecture style by synthesizing the evaluations of applicability, benefits, and drawbacks.
Step 3. Integrate Architecture Styles
Incorporate the selected architecture styles into the schematic architecture of the target system.
Task 1. Integrate Architecture Styles with Tiers
Incorporate architecture styles that define structural organization in terms of system tiers.
Task 2. Integrate Architecture Styles with Services
Incorporate architecture styles that utilize external services delivered over a network.
Task 3. Integrate Architecture Styles with Layers
Incorporate architecture styles that follow a layered architectural approach.
Task 4. Integrate Architecture Styles with Behavior
Incorporate architecture styles that specify behavioral structures, such as invocation or interaction paradigms.
Task 5. Integrate Architecture Styles with Adaptability
Incorporate architecture styles that enhance the adaptability and flexibility of the target system.
Task 6. Integrate Remaining Architecture Styles
Incorporate any remaining architecture styles that have not yet been addressed in the preceding integration tasks.
Step 4. Refine Schematic Architecture
Refine the schematic architecture by making additions and modifications to ensure it fully meets the requirements of the target system.
Task 1. Refine Structural Elements
Further develop and clarify the structural elements of the schematic architecture to ensure completeness and coherence.
Task 2. Refine Connectors
Refine the connectors within the schematic architecture, detailing the interaction mechanisms and communication paths among components.
A4a — Design for Functional View
Design the functional view of the target system by refining system functionality into architectural functional components, allocating responsibilities, defining interfaces, and addressing functional variability.
Step 2. Define Functional Components
Step 3. Allocate Functional Components
Step 1. Refine Use Case Model
Refine the use case model so that it provides sufficient architectural detail for designing the functional structure of the system.
Task 1. Review the Use Case Model
Review the use cases, actors, system boundary, and relationships identified during requirements refinement and system context analysis.
Task 2. Refine Use Cases for Architecture Design
Refine use cases that have architectural significance by clarifying responsibilities, major interactions, dependencies, and exceptional behavior.
Task 3. Identify Common and Shared Functionality
Identify functionality that is common to multiple use cases or can be reused across different parts of the system.
Task 4. Validate the Refined Use Case Model
Check that the refined use case model sufficiently represents the functional requirements needed for functional architecture design.
Step 2. Define Functional Components
Define the major functional components that realize the required functionality of the system.
Task 1. Identify Candidate Functional Components
Identify candidate components based on major system functions, related use cases, functional responsibilities, and architectural concerns.
Task 2. Group Related Responsibilities
Group closely related responsibilities into cohesive functional components.
Task 3. Define Component Responsibilities
Specify the primary responsibilities and services provided by each functional component.
Task 4. Review Component Cohesion and Coupling
Review the candidate components to improve cohesion within components and reduce unnecessary dependencies between components.
Step 3. Allocate Functional Components
Allocate system functions and use-case responsibilities to the defined functional components.
Task 1. Map Functions to Functional Components
Determine which functional component is responsible for realizing each major system function.
Task 2. Allocate Use-Case Responsibilities
Allocate the responsibilities involved in each architecturally significant use case to appropriate functional components.
Task 3. Identify Shared Responsibilities
Identify responsibilities that involve multiple components and clarify how those components collaborate.
Task 4. Document the Allocation
Record the allocation between system functionality and functional components, for example using a Functional Component Allocation Table.
Step 4. Define Functional Component Interfaces
Define the interfaces through which functional components provide services and collaborate with other components.
Task 1. Identify Required Interactions
Identify interactions among functional components based on use-case realization and functional dependencies.
Task 2. Define Provided Interfaces
Specify the services or operations that each functional component provides to other components.
Task 3. Define Required Interfaces
Specify the services that each functional component requires from other components.
Task 4. Review Interface Dependencies
Review the interfaces to reduce unnecessary dependencies and ensure clear separation of responsibilities.
Step 5. Design for Functional Variability
Design variation points where system functionality may differ across products, configurations, deployment contexts, or future versions.
Task 1. Identify Functional Variabilities
Identify functional requirements that may vary depending on product configuration, user type, operating environment, or expected future evolution.
Task 2. Define Variation Points
Determine where variability should be represented within the functional architecture.
Task 3. Define Functional Variants
Specify the alternative functional behaviors or components associated with each variation point.
Task 4. Design Variability Mechanisms
Determine how the functional architecture will support the variants while minimizing unnecessary dependencies and duplicated functionality.
Task 5. Validate Functional Variability
Check that the proposed variability design supports the required alternatives without compromising the clarity and maintainability of the functional architecture.
A4b — Design for Information View
Design the information view of the target system by refining persistent information structures, defining data components, allocating them to the architecture, specifying their interfaces, and designing appropriate persistence mechanisms.
Step 1. Refine Persistent Object Model
Step 2. Define Data Components
Step 3. Allocate Data Components
Step 1. Refine Persistent Object Model
Refine the persistent object model so that it provides sufficient architectural detail for designing the information structure of the system.
Task 1. Refine Persistent Object Classes
Review and refine the object classes that represent information requiring persistent storage.
Task 2. Refine Relationships between Classes
Refine relationships among persistent object classes, including their associations and cardinalities.
Task 3. Define Persistent Attributes
Identify and define the essential attributes of persistent object classes that need to be maintained by the system.
Step 2. Define Data Components
Define the architectural data components needed to manage the persistent information of the system.
Task 1. Identify Data Components from the Class Diagram
Analyze the persistent object model and identify candidate data components that encapsulate related persistent information.
Task 2. Identify Data Components from Architecture Styles
Identify additional data components required by the selected architecture styles and architectural structure.
Task 3. Refine Data Components
Review and refine the identified data components to ensure clear responsibilities and appropriate organization of persistent information.
Step 3. Allocate Data Components
Allocate the defined data components to appropriate locations in the schematic architecture.
Task 1. Assign Data Components onto Tiers
Determine the architectural tiers in which the data components should reside.
Task 2. Identify Data Placeholders
Identify the placeholders in the schematic architecture that will contain or manage persistent data.
Task 3. Allocate Data Components onto Placeholders
Map each data component to an appropriate data placeholder in the architecture.
Task 4. Review Data Component Allocation
Check the allocation for consistency with functional responsibilities, architectural styles, performance needs, and data-management requirements.
Step 4. Define Data Component Interfaces
Define the interfaces through which other architectural components access and manipulate persistent data.
Task 1. Select Target Data Components
Identify the data components for which explicit architectural interfaces need to be defined.
Task 2. Define Data Component Interfaces
Specify the services and operations provided by each selected data component for creating, retrieving, updating, deleting, and otherwise managing persistent information.
Task 3. Review Interface Dependencies
Review dependencies between data components and their clients to maintain clear responsibilities and minimize unnecessary coupling.
Step 5. Design Object Persistence
Determine how persistent objects and data components will be physically stored and managed.
Task 1. Determine Persistence Medium
Select appropriate persistence media, such as relational databases, NoSQL databases, files, cloud storage, or other persistent storage mechanisms.
Task 2. Apply the Persistence Medium
Map persistent objects and data components to the selected persistence technologies and storage structures.
Task 3. Design Data Resilience
Design mechanisms for maintaining data availability, integrity, backup, recovery, replication, and other required resilience characteristics.
A4c — Design for Behavior View
Design the behavior view of the target system by refining overall control flow, identifying important behavioral elements, defining detailed control flows, and integrating them into a coherent representation of system runtime behavior.
Step 1. Refine Overall Control Flow
Step 2. Identify Key Behavioral Elements
Step 1. Refine Overall Control Flow
Refine the overall control flow of the target system so that major runtime behavior, execution paths, and control relationships are clearly represented.
Task 1. Review Existing Control Flow
Review the behavioral information identified during earlier architecture activities, including major scenarios, interactions, events, and control dependencies.
Task 2. Identify Major Control Paths
Identify the major execution paths through which system functions are initiated, coordinated, and completed.
Task 3. Refine Decision and Control Points
Clarify important decisions, branches, synchronization points, and conditions that affect system behavior.
Task 4. Validate the Overall Control Flow
Check that the refined flow adequately represents the major runtime behavior required by the system.
Step 2. Identify Key Behavioral Elements
Identify the architectural elements that play important roles in controlling or coordinating system behavior.
Task 1. Identify Control-Oriented Components
Identify components that initiate, coordinate, supervise, or otherwise influence system execution.
Task 2. Identify Events and Triggers
Identify important internal and external events that initiate or alter system behavior.
Task 3. Identify Behavioral States
Identify important states that influence how architectural elements respond to events or requests.
Task 4. Identify Behavioral Dependencies
Identify dependencies among components, events, states, and control responsibilities.
Step 3. Define Detailed Control Flows
Define detailed control flows for architecturally significant behaviors and scenarios.
Task 1. Select Architecturally Significant Scenarios
Select scenarios whose runtime behavior needs to be represented explicitly in the architecture.
Task 2. Define Interaction Sequences
Specify the sequence of interactions among architectural components for each selected scenario.
Task 3. Define Conditions and Alternative Flows
Represent important conditions, alternatives, exceptions, and concurrent behavior.
Task 4. Document Detailed Control Flows
Document the resulting behavior using appropriate behavioral models, such as activity diagrams, sequence diagrams, or state-based representations.
Step 4. Integrate Refined Control Flows
Integrate the detailed control flows into a consistent behavior view of the overall architecture.
Task 1. Combine Related Control Flows
Combine behavioral models that involve related components, events, or runtime responsibilities.
Task 2. Resolve Behavioral Inconsistencies
Identify and resolve conflicting assumptions, inconsistent sequencing, or incompatible control responsibilities.
Task 3. Check Consistency with Other Views
Verify that the behavior view is consistent with the functional and information views.
Task 4. Finalize the Behavior View
Consolidate the refined behavioral models into the architecture description.
A4d — Design for Deployment View
Design the deployment view of the target system by defining computing devices, execution environments, network connectivity, and the allocation of software artifacts to the deployment infrastructure.
Step 1. Define Computing Devices
Step 1. Define Computing Devices
Define the physical computing devices required to execute and support the software system.
Task 1. Determine Computing Device Nodes
Identify the physical computing devices required by the target system, such as servers, client devices, embedded devices, mobile devices, gateways, or other computing platforms.
Task 2. Represent Computing Device Nodes
Represent the identified devices as deployment nodes and specify their relevant characteristics and roles in the deployment architecture.
Step 2. Define Execution Environments
Define the execution environments in which software components and artifacts will run.
Task 1. Determine Execution Environments
Identify required execution environments, such as operating systems, virtual machines, containers, application servers, runtime platforms, or cloud execution environments.
Task 2. Represent Execution Environment Nodes
Represent the execution environments as deployment nodes and associate them with the appropriate computing devices.
Step 3. Define Connectivity
Define the communication paths and network configuration among deployment nodes.
Task 1. Determine Communication Paths
Identify the communication paths required among computing devices and execution environments.
Task 2. Specify Network Configuration
Specify the network configuration associated with the communication paths, including relevant protocols, topology, and communication characteristics.
Step 4. Allocate Software Artifacts
Allocate deployable software artifacts to the appropriate execution environments and computing devices.
Task 1. Identify Software Artifacts to Deploy
Identify the software artifacts that must be deployed, such as executable files, services, libraries, containers, configuration files, models, or other deployable units.
Task 2. Allocate Software Artifacts
Assign each software artifact to the appropriate execution environment or computing device and represent the allocation in the deployment view.
A5 — Design for Non-Functional Requirements
Augment the view-based architecture design with architectural tactics that satisfy the identified non-functional requirements. A5 systematically derives architectural criteria from underlying facts and policies, develops and evaluates candidate tactics, integrates selected tactics into the architectural views, and validates conformance.
Step 1. Identify Facts and Policies
Step 2. Define Criteria for Tactics
Step 3. Define Candidate Tactics
Step 4. Evaluate Candidate Tactics
Step 1. Identify Facts and Policies
Identify the facts and organizational policies underlying each non-functional requirement so that architectural decisions are grounded in relevant system, operational, technical, and organizational context.
Task 1. Identify Underlying Facts
Identify relevant facts concerning the system, its domain, operating environment, technologies, users, resources, constraints, and other conditions that influence the non-functional requirement.
Task 2. Identify Underlying Policies
Identify organizational rules, priorities, restrictions, commitments, operating principles, or other policies that architectural decisions must respect.
Step 2. Define Criteria for Tactics
Derive architectural criteria from the identified facts and policies to guide the selection and evaluation of architectural tactics.
Task 1. Derive Criteria from Facts
Translate relevant facts into architectural criteria that specify conditions or characteristics that candidate tactics should satisfy.
Task 2. Derive Criteria from Policies
Translate relevant organizational policies into architectural criteria that constrain or guide architectural decisions.
Step 3. Define Candidate Tactics
Develop candidate architectural tactics that can satisfy the non-functional requirements and the architectural criteria derived in the preceding step.
Task 1. Propose Candidate Architecture Tactics
Identify alternative architectural tactics that may address the target non-functional requirement.
Task 2. Detail Candidate Architecture Tactics
Specify each candidate tactic in sufficient technical and operational detail to support subsequent evaluation and architectural integration.
Step 4. Evaluate Candidate Tactics
Evaluate the candidate architectural tactics and determine which tactics are appropriate for inclusion in the architecture.
Task 1. Analyze Costs and Benefits
Analyze the expected benefits, implementation costs, architectural impacts, risks, and tradeoffs associated with each candidate tactic.
Task 2. Determine the Applicability of Architecture Tactics
Assess the applicability of each tactic against the architectural criteria and select the tactics that provide an appropriate balance of effectiveness and feasibility.
Step 5. Integrate Selected Tactics
Integrate the selected architectural tactics into the appropriate architectural views.
Task 1. Analyze Impacts of Architecture Tactics
Determine how each selected tactic affects the functional, information, behavior, deployment, and other relevant architectural elements.
Task 2. Apply Impacts of Architecture Tactics
Modify the affected architectural views and elements to incorporate the selected tactics consistently.
Step 6. Validate Conformance
Validate that the resulting architecture conforms to the specified functional and non-functional requirements.
Task 1. Validate Functional Conformance
Check that the architecture continues to support the required system functionality after the selected tactics have been integrated.
Task 2. Validate Non-Functional Conformance
Check that the architecture adequately addresses the target non-functional requirements and their associated architectural criteria.
A6 — Architecture Evaluation
Evaluate the target system architecture to identify potential risks, issues, drawbacks, and areas for improvement, and to verify that the architecture adequately supports the functional and non-functional requirements.
Step 1. Identify Target Elements for Evaluation
Step 1. Identify Target Elements for Evaluation
Identify the architectural elements that should be evaluated based on their significance, risk, complexity, and potential impact on system quality.
Task 1. List Elements in Architecture Description
Identify and list the architectural elements represented in the architecture description, including relevant components, connectors, interfaces, views, design decisions, and architectural tactics.
Task 2. Select Target Elements for Evaluation
Select the architectural elements that require focused evaluation based on their importance, associated risks, architectural significance, and relationship to critical functional and non-functional requirements.
Step 2. Define Architecture Evaluation Methods
Determine appropriate approaches and methods for evaluating the selected architectural elements.
Task 1. Select Architecture Evaluation Approaches
Select suitable evaluation approaches based on the evaluation objectives, characteristics of the architecture, available resources, and required level of rigor.
Task 2. Select Evaluation Methods within Approaches
Select specific evaluation methods within the chosen approaches that can effectively assess the target architectural elements and relevant requirements.
Step 3. Apply Architecture Evaluation Methods
Apply the selected evaluation methods and incorporate the resulting findings into the architecture.
Task 1. Evaluate Architecture Design with Selected Methods
Evaluate the selected architectural elements using the defined methods and identify risks, weaknesses, inconsistencies, trade-offs, and opportunities for improvement.
Task 2. Incorporate Evaluation Results into Architecture
Analyze the evaluation results and refine the architecture design, architecture description, or related design decisions as necessary.