| Description |
Defines
how the persistence aspect of the solution will be designed. In the case
of a relational database, this task would begin to define the entity-relationship
model. In the case of an object database, this task would define how the
database will be used to store the objects (e.g. containerization strategy
for Objectivity). |
| Risk
& Impact |
This
task serves two purposes. It provides a starting point for persistent which
can be evolved and proven throughout the Object Interaction Diagrams to
meet the business and technical needs of the project. It also serves as
a reference point to judge the solution object model against, since they
both must reflect a consistent semantic model. In the case of a relational
database, the schema needs to be defined. Inadequate effort in this task
may lead to a substandard design, exhibiting poor performance and/or a
persistence solution incapable of storing the applications objects. |
| Inputs: |
Domain
Model Design |
| Upstream
Tasks: |
Domain
Model Design |
| Downstream
Tasks: |
Event
Diagramming |
| Questions
Asked: |
-
What are the actors defined in the use cases?
-
What are the properties of the actors in the use cases?
-
What are entities are implied by the use cases?
-
What entities does the application architecture and design imply?
-
What entities does the reuse analysis imply?
|
| Iterates
with: |
Requirements
Use Cases |
| Deliverables: |
Logical
Database Model – In the case of a relational database, this document
is an ERA diagram showing the entities, relationships and attributes in
the database schema. In the case of an object database, the documents describes
the organization strategy used in the database, including containerization,
name roots, access strategies, etc. |