Section A.3. Design Decisions


A.3. 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 versus a many-to-one association), and they can be elaborated with explicit hints (such as differentiating the three earlier cases).

At the level of code generation, 3GLs have hints, although they work at a much lower level of abstraction. Programmers switch on code optimization or debugging information. As a result, the bytecode/object code becomes vastly different, with different performance characteristics.

Figure A-2 shows how MDA records design decisions as marks. A transformation function uses related marks, held in a subordinate marking model, along with the principle model, either PIM or PSM as the case may be, to create the next, more concrete model. Partitioning the marks into separate marking models keeps the principle model pure, and the marks related to different concerns separate from each other. Were the downstream technology to change, the related marks could be dropped without disturbing the principle model.

Figure A-2. Tightly coupled marking models keep technology decisions out of the principal models


Model elaboration is the intentional enrichment of a generated model. Generated models likely have need tailoring or optimization (otherwise, why have them?). Modelers assign or update the marks to control the transformation function. Programmers will add custom code in protected areas. Marks record both the updates and whether the marks originate from humans.

The unpolluted model, be it PIM or PSM, remains the same no matter how many downstream technologies there are. The principle model remains unchanged, regardless of whether a dependent model appears or disappears.

With the technology concerns partitioned from the principle model and each other, the marking models can evolve independently of each other. The technology functions can create default marks for elements. Technical modelers, who are experts in different fields, elaborate their models separately.




UML 2.0 in a Nutshell
UML 2.0 in a Nutshell (In a Nutshell (OReilly))
ISBN: 0596007957
EAN: 2147483647
Year: 2005
Pages: 132

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net