1. RUP Design RUP Artifacts and Deliverables
RUP Analysis & Design Workflow

2. Purpose of Analysis & Design
To transform the requirements into a design of the system to-be.
To evolve a robust architecture for the system.
To adapt the design to match the implementation environment, designing it for performance.

3. Analysis & Design Workflow

4. Define Candidate Architecture
Create an initial sketch of the architecture of the system
Identify analysis classes from the architecturally significant use cases
Update the use-case realizations with analysis class interactions

5. Create Initial Architecture Sketch
Define an initial set of architecturally significant elements to be used as the basis for analysis
Define an initial set of analysis mechanisms
Define the initial layering and organization of the system
Define the use-case realizations to be addressed in the current iteration

6. Define Candidate Architecture - Staffing
These activities are best carried out by a small team staffed by cross-functional team members.
Issues that are typically architecturally significant include performance, scaling, process and thread synchronization, and distribution.
The team should also include members with domain experience who can identify key abstractions.
The team should also have experience with model organization and layering.
The team will need to be able to pull all these disparate threads into a cohesive, coherent(albeit preliminary) architecture.

7. Define Candidate Architecture Workflow

8. Login Use Case Realization

9. Login Class Diagram

10. Analysis & Design Workflow

11. Analyze Behavior - Purpose
Transform the behavioral descriptions provided by the use cases into a set of elements upon which the design can be based

12. Analyze Behavior - Staffing
The Activity: Use-Case Analysis is best conducted by a small group with a blend of skills; staffing guidelines are presented in Work Guidelines: Use-Case Analysis Workshop.
The Activity: IdentifyDesign Elements requires a broader perspective of the architecture and the results of other use-case analysis workshops, and requires some experience in the implementation technology and any frameworks being used on the project.
Reviews should be staffed with people who have both in-depth knowledge of the implementation technologies as well as an understanding of the problem domain.

13. Analyze Behavior Workflow

14. Analysis & Design Workflow

15. Refine the Architecture - Purpose
Provide the natural transition from analysis activities to design activities, identifying:
- appropriate design elements from analysis elements
- appropriate design mechanisms from related analysis mechanisms
Maintain the consistency and integrity of the architecture, ensuring that:
- new design elements identified for the current iteration are integrated with pre-existing design elements.
- maximal re-use of available components and design elements is achieved as early as possible in the design effort.
Describe the organization of the system's run-time and deployment architecture
Organize the implementation model so as to make the transition between design and implementation seamless

16. Refine the Architecture - Staffing
These activities are best carried out by a small team staffed by cross-functional team members.
The team should also include members with domain experience who can identify key abstractions.
The team should also have experience with model organization and layering.
The team will need to be able to pull all these disparate threads into a cohesive, coherent (albeit preliminary) architecture.
The architecture team will need to shift members or expand to include people with distribution and deployment expertise (if those issues are architecturally significant).

17. Refine the Architecture Workflow

18. Software Architecture Document - Purpose
The software architecture document provides a comprehensive overview of the architecture of the software system. It serves as a communication medium between the architect and other project team members regarding architecturally significant decisions which have been made on the project.

19. Software Architecture Document Use Case View

20. Software Architecture Document Logical View – Architecture Overview

21. Software Architecture Document Process View - Processes

22. Software Architecture Document Process View – Process to Design

23. Software Architecture Document Process View – Process to Design Model Dependencies

24. Analysis & Design Workflow

25. Design Components - Purpose
Refine the definitions of design elements by working out the 'details' of how the design elements implement the behavior required of them.
Refine and update the use-case realizations based on new design element identified (i.e. keeping the use-case realizations updated)
Reviewing the design as it evolves
Implementing the design elements as components
Testing the implemented components to verify functionality and satisfaction of requirements at the component/unit level

26. Design Components - Staffing
Typically, one person or a small team is responsible for a set of design elements, usually one or more packages or subsystems containing other design elements.
The individuals or teams responsible for designing classes should be knowledgeable in the implementation language as well as possessing expertise in the algorithms or technologies to be employed by the class.
Individuals or teams responsible for subsystems should be more generalists, able to make decisions on the proper partitioning of functionality between design elements, and able to understand the inherent trade-offs involved in various design alternatives.
The individuals or teams responsible for use-case realizations need to have broader understanding of the behavior required by the use cases and of the trade-offs of different approaches to allocating this behavioramongst design elements.

27. Design Components Workflow

28. Analysis & Design Workflow

29. Design Real Time Components - Purpose
Refine the definitions of design elements (including capsules and protocols) by working out the 'details' of how the design elements implement the behavior required of them.
Refine and update the use-case realizations based on new design element identified (i.e., keeping the use-case realizations updated)
Reviewing the design as it evolves
Implementing the design elements as components
Testing the implemented components to verify functionality and satisfaction of requirements at the component/unit level

30. Design Real Time Components Workflow

31. Analysis & Design Workflow

32. Design the Database - Purpose
Identify the persistent classes in the design
Design appropriate database structures to store the persistent classes
Define mechanisms and strategies for storing and retrieving persistent data in such a way that the performance criteria for the system are met

33. Design the Database - Staffing
The Designers responsible for persistent classes need to have an understanding of the persistence in general and the persistence mechanisms in specific.
The Database Designer needs to understand the persistent classes in the design model and so must have a working understanding of object-oriented design and implementation techniques.
The Database Designer also needs a strong background in database concurrency and distribution issues.

34. Design the Database Workflow

35. Analysis & Design Activity Overview

36. Analysis & Design Artifact Overview