15. Platform Package
Overview
Platform package defines a set of meta-model element whose purpose is to represent the runtime operating environments of existing software systems. Application code is not self-contained as it is determined not only by the selected programming languages, but also by the selected Runtime platform. Platform elements determine the execution context for the application. Platform package defines meta-model elements that represent common Runtime platform concerns:
- Runtime platform consists of many diverse elements (platform parts).
- Platform provides resources to deployment components.
- Platform provides services that are related to resources.
- Application code invokes services to manage the life-cycle of a resource.
- Control flow between application components is often determined by the platform.
- Platform provides error handling across application components.
- Platform provides integration of application components.
Examples of Platform Parts include UNIX OS File System, UNIX OS process management system, Windows 2000, OS/390, Java (J2SE), Perl language Runtime support, IBM CICS TS, IBM MQSeries, Jakarta Struts, BEA Tuxedo, CORBA, HTTP, TCP/IP, Eclipse, EJB, JMS, Database middleware, Servlets.
Organization of the Platform Package
The Platform package consists of the following 10 class diagrams:
- PlatformModel
- PlatformInheritances
- PlatformResources
- PlatformRelations
- PlatformActions
- ProvisioningRelations
- Deployment
- RuntimeResources
- RuntimeActions
- ExtendedPlatformElements
The Platform package depends on the following packages:
PlatformModel Class Diagram
The PlatformModel class diagram The PlatformModel follows the uniform pattern for extending KDM Framework followed by each KDM model. The classes and associations of the PlatformModel diagram are shown in See – PlatformModel Class Diagram..
– PlatformModel Class Diagram
PlatformModel Class
Platform model defines one of the architectural views in support of the principle of separation of concerns in KDM models. PlatformModel provides a container for platform elements.
| platformElement:PlatformElement[0..*] | owned platform elements |
PlatformModel is a logical container for platform elements. It is the implementer’s responsibility to arrange platform elements into one or more platform models.
AbstractPlatformElement Class (abstract)
The AbstractPlatformElement is an abstract meta-model element which represents entities of the operating environments of software systems.
implementation AbstractCodeElement should be owned by some CodeModel
implementation AbstractCodeElement should be subclasses of ComputationalObject or ActionElement
abstraction ActionElement should be owned by the same PlatformModel
An instance of an AbstractPlatformElement represents either an instance of some runtime resource or some API call that manages some runtime resource. The implementation association links AbstractPlatformElement to the corresponding elements of some CodeModel. “Abstraction” action elements can be used to specify precise semantics of the PlatformElement.
AbstractPlatformRelationship Class (abstract)
The AbstractPlatformRelationship is an abstract meta-model element which represents associations between platform entities.
An instance of an AbstractPlatformRelationship represents structural association between two runtime resources.
PlatformInheritances Class Diagram
The PlatformInheritances class diagram represents inheritances of the meta-modeling elements of the Platform package. The classes and associations of the PlatformInheritances diagram are shown in See – PlatformInheritances Class Diagram..
– PlatformInheritances Class Diagram
PlatformResources Class Diagram
The PlatformResources class diagram defines the meta-model elements to represent platform resources. The classes and associations of the PlatformResources diagram are shown in See – PlatformResources Class Diagram..
– PlatformResources Class Diagram
ResourceType Class
The ResourceType is a meta-model element that represents a platform resource. The purpose of a platform is to simplify application development by closing the gap between the application domain and the facilities that are available to application programmers. The latter are referred to as platform resources. Examples of resource types include UNIX File, UNIX IO Stream, UNIX socket, UNIX Process, UNIX thread, AWT widget, CICS File, CICS transaction, UNIX semaphore, UNIX shared memory segment, OS/390 VSAM file, JDBC connection, HTTP session, HTTP request, UNIX memory block, CICS commarea, COBOL file.
KDM introduces Platform Resource as an explicit abstraction in order to separate the explicit parts that are written by application programmers from parts that are provided by the platform. The underlying implementation details may be quite complex, for example, marshaled call includes client stubs, skeletons, platform-managers. The type of the Platform Resource denotes the semantics of the resource.
Platform resources can be further subdivided into smaller groups of services (resource types). Platform resources are usually grouped into platform stacks. Platform resource is an element of the overall platform used by a particular system. Complete Platform is the entire collection of platform resources used by the segments of the system. Platform resource may be associated with logical packages for a particular programming language.
| platformElement:AbstractPlatformElement[0..*] | The set of platform elements which are owned by the given ResourceType. |
ResourceType may represent an individual runtime resource instance or a container for several such instances.
It is the implementer’s responsibility to identify runtime resources used by the existing software system according to the semantics of the platform used by the existing system, resource configuration files and other appropriate sources of information.
Specific subclasses of ResourceType define specific categories of resources available to implementers. Other types of resources can be represented by an generic instance of ResourceType meta-model element with a stereotype.
NamingResource Class
NamingResource represents platform resources that provide registration and lookup services (e.g., registry). In the meta-model NamingResource is a subclass of ResourceType.
MarshalledResource Class
MarshalledResource represents platform resources that provide intercomponent communication via remote synchronous calls. For example, RPC, CORBA method call, Java remote method invocation. In the meta-model MarshalledResource is a subclass of ResourceType.
MessagingResource Class
MessagingResource represents platform resources that provide intercomponent communication via asynchronous messages (e.g., IBM MQSeries messages).
FileResource Class
FileResource represents platform resources that provide any non-database related storage. In the meta-model the FileResource class is a subclass of ResourceType. It also implements the DataInterface so that this class can be the endpoint of Data relations.
ExecutionResource Class
ExecutionResource represents dynamic Runtime elements (e.g., process or thread).
LockResource Class
LockResource represents a synchronization resource common to multithreaded runtime environments.
StreamResource Class
StreamResource represents a simple input/output resource, for example UNIX-like stream.
DataManager Class
DataManager represents a database management system. DataManager is associated with particular data elements that represent the data description of the data managed by the data manager.
PlatformEvent class
The PlatformEvent class is a meta-model element representing various events and callbacks associated with runtime platforms. This class follows the KDM event pattern, common to Resource Layer packages.
| kind:String | represents the nature of the action performed by this Event |
PlatformAction class
PlatformAction class follow the pattern of a “resource action” class, specific to the Platform package. The nature of the action represented by a particular element is designated by its “kind” attribute. Descriptions of the common platform action kind are provided in Appendix 2. Resource Layer actions.
| kind:String | represents the nature of the action performed by this element |
| platformElement:PlatformEvent[0..*] | The set of platform events which are owned by the given PlatformAction. |
ExternalActor Class
ExternalActor is a meta-model element that represents entities outside of the boundary of the software system being modeled. For example, external actor can be a user of the system. External actors interact with the software system.
In the meta-model ExternalActor is a PlatformElement. Semantics of ExternalActors is outside of the scope of KDM.
PlatformRelations Class Diagram
The PlatformRelations class diagram defines associations between ResourceTypes.
The classes and associations of the PlatformRelations diagram are shown in See – PlatformRelations Class Diagram..
– PlatformRelations Class Diagram
BindsTo Class
BindsTo defines a semantic association between two ResourceTypes.
| from:ResourceType[1] | The ResourceType which is the source of the relationship (the from-endpoint). |
| to:ResourceType[1] | The ResourceType which is the target of the relationship (the to-endpoint). |
ProvisioningRelations Class Diagram
The ProvisioningRelations class diagram defines meta-model elements that represent the physical elements of the Runtime platform that provide certain services and manage resources.
The classes and associations of the ProvisioningRelations diagram are shown in See – ProvisioningRelations Class Diagram..
– ProvisioningRelations Class Diagram
Requires Class
Requires defines semantic relationship between a DeployedComponent and a AbstractPlatformElement.
PlatformActions Class Diagram
The PlatformActions class diagram defines meta-model elements that represent specific actions which are the endpoints of certain Platform relationships. The elements of this diagram extend ActionElement from the KDM Action package.
The classes and associations of the PlatformActions diagram are shown in See – PlatformActions Class Diagram..
– PlatformActions Class Diagram
ManagesResource class
ManagesResource class follows the pattern of a “resource action relationship”. It represents various types of accesses to platform resources that are not related to the flow of data to and from the resource. ManagesResource relationship is similar to Addresses relationship from Action Package. The nature of the operation on the resource is represented by the “kind” attribute of the PlatformAction that owns this relationship through the “abstracted” action container property.
Action::AbstractActionRelationship
| from:ActionElement[1] | “abstracted” action owned by some resource |
| to:ResourceType[1] | the resource being accessed |
This relationship should not be used in Code models
ReadsResource class
ReadsResource class follows the pattern of a “resource action relationship”. It represents various types of accesses to platform resources where there is a flow of data from the resource. ReadsResource relationship is similar to Reads relationship from Action Package. The nature of the operation on the resource is represented by the “kind” attribute of the PlatformAction that owns this relationship through the “abstracted” action container property.
Action::AbstractActionRelationship
| from:ActionElement[1] | “abstracted” action owned by some resource |
| to:ResourceType[1] | the resource being accessed |
This relationship should not be used in Code models
WritesResource class
WritesResource class follows the pattern of a “resource action relationship”. It represents various types of accesses to platform resources where there is a flow of data to the resource. WritesResource relationship is similar to Writes relationship from Action Package. The nature of the operation on the resource is represented by the “kind” attribute of the PlatformAction that owns this relationship through the “abstracted” action container property.
Action::AbstractActionRelationship
| from:ActionElement[1] | “abstracted” action owned by some resource |
| to:ResourceType[1] | the resource being accessed |
This relationship should not be used in Code models
DefinedBy class
DefinedBy is a meta-model element that represents association between a platform resource and the logical package that describes the interface to this resource. The CodeItem at the to-endpoint of this KDM relationship is usually an interface or a package.
Action::AbstractActionRelationship
| from:ActionElement[1] | “abstracted” action owned by some resource |
| to:CodeItem[1] | the CodeItem describing the resource |
This relationship can not be used in the Code Model
DefinedBy is an optional relationship. It is the implementer’s responsibility to correctly associate the platform resource with the corresponding logical definition of this resource (usually a Signature, an Interface, or a Package). The logical description of the package usually refers to some external implementation, as platform resources are usually described by some third-party packages, provided as part of the runtime platform of the application. Individual API calls corresponding to the given resource, should have the CompliesTo relations to the individual API descriptions the definition represented by the CodeItem at the to-endpoint of the DefinedBy relationship.
Deployment Class Diagram
The Deployment class diagram defines meta-model elements that represent deployment elements and their relations. In particular, the elements of the Deployment diagram address physical structures and how logical components are mapped to these physical structures.
The classes and associations of the Deployment diagram are shown in See – Deployment Class Diagram..
– Deployment Class Diagram
DeployedComponent Class
The DeployedComponent represents a unit of deployment as defined by a particular platform. Major platform parts provide a packaging mechanism of deploying application functionality. Deployment component is a replaceable unit of an application. For example, DLL, shared library, COM, Eclipse plugin, Executable, Jar file, War file for Tomcat, SQL Stored procedure, CORBA module, EJB, JavaBean, Jakarta Struts Action, Jakarta Struts Form.
| groupedCode:Module[0..*] | The code components which are deployed to the target DeployedComponent (KDM grouping association) |
DeployedSoftwareSystem Class
The DeployedSoftwareSystem is a meta-model element that represents an instance of a software system at deployment or at the initialization time. DeployedSoftwareSystem is a physical instance of some logical SoftwareSystem. DeployedSoftwareSystem is associated with a set of DeployedComponents, which correspond to the set of logical components of the logical SoftwareSystem. The logical view of KDM model describes one or more SoftwareSystems. Each SoftwareSystem involves one or more Components. Some components can be involved in more than one SoftwareSystem (allowing description of the so-called Software Product Lines). Each Component involves one or more model Modules. Again, each Module can be involved in more than one Component. Component is a unit of deployment. Each logical component can be deployed multiple times, each time represented by a unique DeploymentComponent element. DeployedSoftwareSystem is a counterpart of the corresponding logical SoftwareSystem.
| groupedComponent:DeployedComponent[0..*] | The set of physical DeployedComponents that make up the target system. The physical components correspond to the logical components of the system. |
Machine Class
The Machine is a meta-model element that represents the hardware node which hosts deployed components.
DeployedResource Class
The DeployedResource is a meta-model element that represents a set of platform resource instances as they are deployed in a particular deployment configuration. DeployedResource is associated with a set of ResourceType elements. DeployedResource provides a unique physical context for a logical resource, as each logical resource can be associated with multiple DeployedResource.
| platformElement:ResourceType[0..*] | The set of ResourceTypes which are deployed into the target DeployedResource. |
RuntimeResources Class Diagram
The RuntimeResources class diagram defines meta-model elements that represent dynamic structures (instances of some logical entities and their relationships) that emerge at the so-called “run time” of the software system. For example, dynamic entities include processes and threads. Instances of processes and threads can be created dynamically and in many cases relations between the dynamically created instances of processes and threads are an essential part of the knowledge of existing systems. Another example of dynamic structures involves deployed components that are loaded dynamically.
The classes and associations of the RuntimeResources diagram are shown in See – RuntimeResources Class Diagram..
– RuntimeResources Class Diagram
RuntimeResource (generic)
The RuntimeResource is a generic meta-model element that represents an entity that has its own execution thread (for example, process or thread). RuntimeResource is subclassed by Process and Thread. In the meta-model RuntimeResource is used as the endpoint of certain relationships.
Process Class
The Process is a meta-model element that represents instances of processes.
Thread Class
The Thread is a meta-model element that represents instances of the so-called threads (light-weight processes).
RuntimeActions Class Diagram
The RuntimeActions class diagram defines meta-model elements that represent specific Runtime actions as the endpoints of certain Runtime relationships. The elements of this diagram extend ActionElement from the KDM Action package.
The classes and associations that make up the RuntimeActions diagram are shown in See – RuntimeActions Class Diagram..
– RuntimeActions Class Diagram
Loads Class
The Loads class is a meta-model element that represents “dynamic loading relationship” between a LoadingService action endpoint and the DeployedComponent.
In the meta-model Loads is a subclass of a generic element RuntimeRelation.
| from:ActionElement[1] | “abstracted” action element owned by some resource |
| to:DeploymentComponent[1] | The component which is being loaded. |
Spawns Class
The Spawns class is a meta-model element that represents “dynamic process creation” or “dynamic thread creation” relationship between a SpawningService action endpoint and the RunnableInterface (Process or Thread).
| from:ActionElement[1] | “abstracted” action element owned by some resource |
| to:RuntimeResource[1] | The runtime resource element (Process or Thread) which is being spawned. |
ExtenededPlatformElements Class Diagram
The ExtendedPlatformElements class diagram defines two “wildcard” generic elements for the code model as determined by the KDM model pattern: a generic platform entity and a generic platform relationship.
The classes and associations of the ExtendedPlatformElements diagram are shown in See – ExtendedPlatformElements Class Diagram..
– ExtendedPlatformElements Class Diagram
PlatformElement Class (generic)
The PlatformElement class is a generic meta-model element that can be used to define new “virtual” meta-model elements through the KDM light-weight extension mechanism.
PlatformElement should have at least one stereotype
A platform entity with under specified semantics. It is a concrete class that can be used as the base element of a new “virtual” meta-model entity types of the platform model. This is one of the KDM extension points which can integrate additional language-specific, application-specific or implementer-specific pieces of knowledge into the standard KDM representation.
PlatformRelationship Class (generic)
The PlatformRelationship class is a generic meta-model element that can be used to define new “virtual” meta-model elements through the KDM light-weight extension mechanism.
| from:AbstractPlatformElement[1] | The platform element endpoint |
| to:KDMEntity[1] | the target of the relationship |
PlatformRelationship should have at least one stereotype
A platform relationship with under specified semantics. It is a concrete class that can be used as the base element of a new “virtual” meta-model relationship types of the platform model. This is one of the KDM extension points which can integrate additional language-specific, application-specific or implementer-specific pieces of knowledge into the standard KDM representation.