As an example of design decisions as mapping functions, let's look at the transition between an analysis model and a design model. Assume that the analysis model contains the elements Bank, Customer, Account, and Transfer, as described on page 49.
Now let's transform this model to a design model. One observation we can make immediately is that some information from the application has to outlive the lifetime of the software system, while others do not. Happily, Enterprise Java Beans (EJBs) provide two forms of beans that correspond to these two needs. An entity bean is a remotely accessible object that can live for the lifetime of the software system and whose state is stored in and loaded from an underlying database. A stateful session bean is a remotely accessible object that lives for the life of a client session.
The result appears on page 50. This looks fine, doesn't it? But what were the rules and patterns by which we arrived at these decisions for transforming the original analysis model into this model?
Analysis Model Information
- knows its Customers and its Accounts
- can establish and abolish relationships with Customers
- knows his or her name
- can open Accounts
- can close an Account he or she owns
- knows the Accounts he or she owns
- can command the Transfer of an amount of money from an Account he or she owns to another Account
- knows its account number
- knows its balance
- knows the Customer who owns it
- can withdraw an amount of money from its balance
- can deposit an amount of money to its balance
- knows the amount of money to transfer
- knows its source and target Accounts
- executes by withdrawing the specified amount of money from its source Account and depositing it to its target Account
With regard to the lifetime of the Bank and its Customers, Accounts, and Transfers in the scope of the modeled area of discourse, the analysis model states the following:
A Bank exists for the lifetime of the software system.
A Customer exists from the moment the customer has entered into a relationship with the bank until the moment the Customer has closed all of his or her Accounts and has quit the relationship with the bank.
An Account exists from the moment it has been opened until the moment it has been closed.
A Transfer exists from the moment it has been commanded by a Customer until the moment it has been executed.
Design Model Information
- is an entity bean with persistent attributes pointing to its Customers and Accounts
- has operations for establishing and abolishing relationships with Customers
- is an entity bean with persistent attributes holding his or her name and pointing to his or her Accounts
- has operations for opening and closing Accounts and for commanding Transfers
- is an entity bean with persistent attributes holding its account number and balance and pointing to its Customer
- has operations for withdrawing and depositing amounts of money
- is a stateful session bean with transient attributes holding the amount of money and pointing to the source and target Accounts
- has an operation for executing the transfer
First, we visited the elements of the analysis model one by one and examined their properties. Then, we looked for properties that are expressible in EJB, by digging into our EJB treasure chest and looking for design notions that would best reflect the input model's properties, and then constraining the reasonable choices for dependent model elements once we mapped a model element.
The specific rules we came up with include the following:
A class whose instances need to persist over the lifetime of the software system shall be represented as an entity bean.
A class whose instances need to persist for some indeterminate time shorter than the lifetime of the system but longer than any particular execution of system functions shall also be represented as an entity bean.
A class whose instances exist only for a relatively brief period of time, and that carry information relating to entity beans, shall be represented as a stateful session bean.
Every entity bean and stateful session bean shall have attributes that reflect necessary information about associations in the analysis model.
These rules make up a mapping function, and the particular mapping of the banking system's analysis model is an application of this function. Contrast this with a code-driven development process, where the mapping rules are implicit and lost once executed. As a consequence, they can't be repeated on the same model, nor can they be applied on a model that requires a similar design.