A.2. The Models of MDA Models play a big role in MDA. As a framework for building systems, MDA abstracts systems into abstraction layers. Traditionally OOAD had analysis, detailed design and code roughly representing a system's business perspective, the architectural/technological perspective, and the implementation perspective. MDA adds one abstraction on top, representing the business context of the system. Figure A-1 shows the different abstraction layers and their associated MDA models. Abstraction increases toward the left and concreteness increases toward the right. Concrete models outnumber abstract models. In general, the abstract begets the concrete; as each model becomes more concrete, it realizes the abstractions with respect to one technology or platform. The inverse, making abstract models from the concrete, also known as reverse engineering, rarely happens, except when the starting point is code. Even then because the system must support a business, starting from the business needs is generally more appropriate. Figure A-1. An example of MDA models and their relationship 
The abstraction models match well with the conceptual layers of a system:
Computational-independent model (CIM) The CIM represents the highest-level business model. The CIM uses a specialized business process language and not UML, although its language could well be derived from the meta-object facility (MOF). The CIM transcends computer systems. Each process interacts with human workers and/or machine components. The CIM describes these interactions between these processes and the responsibilities of each worker, be it human or otherwise. Anyone understanding business and business processes can understand a CIM. It avoids specialized knowledge of procedures internal to a worker computer system, such as accounting procedures or sales commissions.
Platform-independent model (PIM) A PIM represents the business model to be implemented by an information system. Commonly, UML or some UML derivative describes the PIM. The PIM describes the processes and structure of the system, without reference to the delivery platforms. The PIM ignores operating systems, programming languages, hardware, and networking. Anyone understanding the specialized domain of the computer system under study can understand the PIM. Although destined to be an information system, the PIM requires no information system background. The PIM is the starting point for MDA discussions in this appendix.
Platform-specific model (PSM) The PSM projects the PIM onto a specific platform. Because one PIM begets multiple PSMs, the PSMs must collaborate to deliver a consistent and complete solution. Commonly, the implementer defines a different UML profile to define the PSM for each target platform. The PSM realizes the PIM as it applies to one specific platform. The PSM deals explicitly with the operating system, programming language, technology platform (e.g., CORBA, .Net, J2EE, or PHP), remote distribution or local collocation. Although porting from one platform or language probably means discarding the PSM, sibling PSMs and the PIM remain unchanged. Despite the need for an understanding of the underlying technology to understand the PSM, the understanding need not be profound. Modelers must know the difference between locally and remotely located components; they don't need to know how to implement or debug them.
Code model The code model represents the deployable code, usually in a high-level language such as XML, Java, C#, C++, VB, HTML, JSP, or ASP. It may or may not be readable. It may or may not be extendable, although often it has extension points in the form of protected code blocks. Ideally, the code model is compile-ready. It doesn't require any further human intervention. Deployment should be automated. In a mature MDA environment, you can think of the code model as you would think of object files or class filesthey're just machine files, opaque to mere mortals. In reality, MDA tools aren't mature. Developers need to understand the technology so that they can debug the application or the deployment. Developers need to load the source into IDEs and debug and deploy as normal. Because little code is actually handwritten, the dilemma is more to deploy correctly than to debug infrastructure.
These models can continue on to the right. We can have a bytecode or link object model, and beyond that a machine code model. Software has matured so much that the vast majority of workers take those models for granted. They just work. If they don't, we just replace them. Figure A-1 shows a one-tier PSM. MDA doesn't restrict PSMs to one tier. Each PSM addresses a different technological layer of a system. If a particular technology lends itself to multiple layers of abstraction, the PSM allows for that too. The specific technologies, and hence, PSMs, are defined by the MDA tool and the architecture it proposes. As a business application developer, you will have to work with that particular framework. |
