Artifact: Platform Independent Model |
|
 |
The Platform Independent Model is a representation of the semantically essential elements of a model that does not contain technology or design-specific detail. |
Domains: Engineering Domain
Extends: Model |
|
Purpose
The purpose of the Platform Independent Model
(PIM) is inherent in the goal of Model-Driven Architecture (MDA). The PIM exists to provide a coherent reusable
application with correct structural and behavioral semantics to enable its effective reuse on different platforms and/or to
provide the ability to easily host multiple applications on the same platform. |
Relationships
Contained Artifacts |
|
Roles | Responsible:
| Modified By:
|
Tasks | Input To:
| Output From:
|
Description
Main Description |
The PIM contains the structural elements required for correctness of the application, their essential
behaviors, and fundamental relations (e.g. associations, aggregations, compositions, and generalizations). The PIM
should be semantically correct and complete enough to execute the functionality of the system, although it may not meet
its Quality of Service (QoS) because performance depends heavily of platform- and
design-specific considerations.
In the Harmony Process, the PIM is one of the primary work artifacts produced during Object Analysis. It is (relatively) devoid of design but contains the essential
elements required in any correct solution to the problem. In the Harmony Design Phases, specific technological solutions are added to the PIM transforming it
into a Platform Specific Model (PSM). This transformation generally occurs either by
translation or elaboration; Harmony recommends a combination of both approaches to efficiently arrive at an optimal
design (PSM).
Historically, the PIM is also known as the essential model.
|
Notation | The PIM is usually represented as one or more related UML models with enough fidelity to support automatic code generation
and execution. |
Selected Representation |
The most important diagrams from the UML are: class, state, and sequence diagrams. Other diagrams add value but
virtually all systems can be specified and created from only these three basic types.
|
Illustrations
Key Considerations
The PIM should contain the structural elements (e.g. classes, objects, functions, variables), their behavior (e.g.,
specified in state machines, activity diagrams, and/or an action language), and the relations among these elements (e.g.
association, aggregation, composition, generalization) that are essential for correctness. This model should
execute and replication the expected functionality requirement of the system. It typically will not meet its QoS but should meet all of the functional requirements. |
Tailoring
Impact of not having | Not having a separately maintained PIM means that it will be more difficult to target the software to a new computing
platform, hardware environment, or software environment. When there is a single anticipated target environment, a separate
PIM probably isn't desired. |
Reasons for not needing |
Having a separately maintained PIM means that should a problem be identified in a derived PSM that affects the PIM, either the PIM must be modified and the PSM
transformations reapplied to regenerate the PSM or the changes must be applied independently to both the PIM and PSM.
When there are anticipated to be multiple target platforms, or a single target platform that is expected to change
throughout its lifecycle, maintaining a separate PIM is probably worth the extra cost.
|
More Information
Checklists |
|
Guidelines |
|
Supporting Materials |
|
|