The purpose of this workflow detail is to identify the design classes to be persisted in a database, and design the corresponding database structures.

Topics

Review Record Analysis Model Data Model Database Designer Database Design Class Design Design Class Review the Design Technical Reviewer Designer Use-Case Realizations Use-Case Model Supplementary Specifications Project Specific Guidelines Design Model Supplementary Specifications


Description To top of page

This Workflow Detail includes:

  • Identifying the persistent classes in the design
  • Designing appropriate database structures to store the persistent classes
  • Defining mechanisms and strategies for storing and retrieving persistent data in such a way that the performance criteria for the system are met

The database and persistent data storage and retrieval mechanisms, are implemented and tested as part of the overall implementation of the components and subsystems of the application.

Related Information To top of page

This section provides links to additional information related to this workflow detail.

Timing To top of page

Starts in Elaboration phase, recurs through Construction and Transition phases.

Optionality To top of page

Optional (required if the system includes a database)

How to Staff To top of page

The Designers responsible for persistent classes need to have an understanding of the persistence in general and the persistence mechanisms in specific. Their primary responsibility is to ensure that persistent classes are identified and that these classes utilize the persistence mechanisms in an appropriate manner. 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.

Work Guidelines To top of page

In the elaboration phase, this workflow focuses on ensuring that the persistence strategy is scalable and that the database design and persistence mechanism will support the throughput requirements of the system. Persistent classes identified in Activity: Class Design are mapped to the persistence mechanism and data-intensive use cases are analyzed to ensure the mechanisms will be scalable. The persistence mechanism and database design is assessed and validated.

Persistence must be treated as an integral part of the design effort, and close collaboration between designers and database designers is essential. Typically the database designer is a 'floating' resource, shared between several teams as a consulting resource to address persistence issues. The database designer is also typically responsible for the persistence mechanisms; if the persistence mechanism is built rather than bought, there will typically be a team of people working on this. Larger projects will typically require a small team of database designers who will need to coordinate work between both design teams and amongst themselves to ensure that persistence is consistently implemented across the project.



© Copyright IBM Corp. 1987, 2004. All Rights Reserved.

Rational Unified Process   2003.06.13