| Artifact: Platform Specific Model |
|
 |
| The Platform Specific Model is an adaptation of a Platform Independent Model (PIM) for execution on a specific target through the selection of technologies, design solutions, or design patterns. |
Domains: Engineering Domain
Extends: Model |
|
Purpose
| The purpose of the Platform-Specific Model (PSM)
is to provide an optimized, targeted implementation of a Platform Independent Model (PIM). |
Relationships
| Contained Artifacts |
|
| Roles | Responsible:
| Modified By:
|
| Tasks | Input To:
| Output From:
|
Description
| Main Description |
The PSM is a model of the system that contains both the essential elements from the PIM and technologies, design patterns, and design solutions meant to optimize the
PSM. In the Harmony/Embedded process, design is all about optimization. While the PIM executes the required
functionality of the system, it does so in an un-optimized fashion. Specific technologies, architectures, design
patterns, and other design decisions are added to provide the PIM functional in a fashion optimized for the intended
use and target platform(s).
|
| Notation | The Unified Modeling Language (UML) is the primary language for the representation of models although other domain-specific
representations (such as Fault Tree Analysis) are often used in conjunction with the UML. |
| 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 PSM must support the functionality of its parent PIM while at
the same time making design and technology decisions that optimize its properties against various design criteria,
including QoS. |
Tailoring
| Impact of not having |
The PSM provides an optimized solution that meets the functional needs of the system, so not having a PSM means that
while the basic functionality may be met, it is certainly likely to be un-optimized and may not meet the system's
required QoS requirements.
|
| Reasons for not needing |
In early prototypes (builds) there is usually more emphasis on key concepts (analysis, requirements, and architecture
concepts) while later prototypes focus more on fine-tuning, optimization, and deployment concerns. Thus, early
prototypes may have very little optimization present.
|
More Information
| Checklists |
|
| Guidelines |
|
| Supporting Materials |
|
|
