UML 2.0 in a Nutshell

Design Decisions

As you've seen in Figure A-1, the number of models increases as you go from the abstract to the concrete. How abstract models become transformed into more concrete models will be discussed a little later. For now, suffice it to say that some function transforms them. Several concrete models can come from a single abstract model. At any one level of abstraction, the model presents the system, without the messiness of implementation details found in the more concrete, downstream models.

Effective model transformation demands precise implementation details. Decisions at one layer imply gross differences at the next, more concrete layer. Consider the following business rules:

• There are only a few (50) states, and they don't change.

• Account transactions can be added, but never changed or deleted, and there can be hundreds of thousands of transactions for one account.

• Account balances are updated very often, but account contact information is updated relatively rarely compared to the number of times it's read. Changes must be audited.

If similar code were to be generated to manage these data entities, you would have a very poor system. To live up to its moniker, MDA must provide some clue in the business model to differentiate between these cases. The business layer doesn't involve itself with design issues such as data access patterns, but it must provide hints. These hints are design decisions . Models provide implicit hints through the structure (a one-to-one association ...