Identifying Models

When selecting problem domains from "thin air," it's best to choose domains that separate cross-cutting concerns into separate subject matters, because this will maximize the independence and reusability of each one. Indeed, many of the successful platforms you already have on hand will already be based on subject matter partitioning. It's also the case that these subject matters are typically aligned along the lines of expected changes.

Assuming the preexistence of several models from which to choose, this is primarily a matter of deciding which ones best fit your overall system. Certainly, within your specific vertical market, you're likely to develop a substantial library of platforms that you can reuse repeatedly.

Other platforms that act as services, like Security, may already exist, so perhaps you can immediately reuse them, or you may need to modify them somewhat before they can be harnessed for your application. You may even have to invent them from scratch, though as the MDA market matures, this will become less and less common.

Still other subject matters may exist as code. The domain chart (Figure 11-1) shows these annotated to indicate whether each domain is realized and whether it requires modification.

In addition, editability has to be designed into the model chain explicitly; edited fragments will have to be retained across several regeneration runs of the edited model. Today, there's no MDA standard for the stereotypes we have used here, nor even for the domain chart. Another standardization task!

MDA Distilled. Principles of Model-Driven Architecture
MDA Distilled. Principles of Model-Driven Architecture
ISBN: B00866PUN2
Year: 2003
Pages: 134 © 2008-2017.
If you may any questions please contact us: