PCM Changelog

Palladio Developer Wiki

• Palladio - Home
• Download
• Features
• Screenshots
• Documentation

Dokumentation des Refactorings des PCM-Metamodells / Documentation of PCM meta model refactorings

Please follow the PCM Metamodelling Process when changing the PCM meta-model.

What to document:

• What entities are new, what relations are new, what was renamed?
• What was the design rationale of the changes?
• Which entities changed semantics?
• For semantic changes of existing concepts: Provide a guide how to migrate from the old to the new concept (e.g. how to query previously existing information after changes)

Further obligatory steps:

• To ensure traceability, do not commit anything else, when committing to pcm.ecore
• Document the changes in the SVN commit log message
• Document the changed model elements in the metamodel
  • Every package and meta-class must have documentation
  • Furthermore, document the most-important associations (i.e. the same meta-class is associated via two different associations OR the names of meta-class and association deviate OR complex concepts represented via association)

Update models after metamodel changes:

• Consider providing a migration script for models or adjust the already available migration scripts, add these to the PCM Model Migration page.
• Refer to PCM Model Migration for initial information on model migration and some model migration scripts.

10.11.2006 (Various Refactorings)

Entities

• GUIDs und Names müssen nicht mehr gemeinsam auftreten, diese beiden Werte sind von nun an unabhängig
• Damit müssen z.B. nicht alle Knoten benannt werden (etwa Start/StopActions), die eine GUID haben

Usage Model

• Branches enthalten nun auch BranchTransitions, die Modellierung des UM wurde hier dem SEFF angeglichen
• BranchTransitions enthalten branchProbabilities (EDouble) mit denen eine Wahrscheinlichkeit ausgedrückt werden kann. Parameterische Abhängikeiten sind hier nicht notwendig.
• Loops benutzen jetzt für die Anzahl der Iterationen Zufallsvariablen (nicht mehr Strings).

Assembly/Composite Component/System

• Vereinheitlichung der o.g. Konzepte im Core Package "composition". Einführung der abstrakten Oberklasse CompositeStructure, die ein Modellelement beschriebt, dass innere Komponenten haben kann.
  • Innere Komponenten sind in ChildComponentContexts enthalten
  • AssemblyConnectoren gehören zur Composite Structure

• Vereinheitlichung des Rollenkonzepts für Components und Systems
  • InterfaceProviding- und InterfaceRequiringEnity sind als abstrakte Characterisierungen dazu gekommen
  • Sowohl System als auch Component erben davon
  • ProvidedRollen hängen an InterfaceProvidingEntities und RequiredRollen an InterfaceRequiringEnity

RDSEFF

• BranchTransitions können jetzt branchProbabilities (EDouble) enthalten. In diesem Fall dürfen jedoch keine RandomVariables für die Spezifikation verwendet werden (bP XOR RV). Bei der Benutzung von branchProbabilities sind diese abhängig voneinander (p, 1-p). Bei der Benutzung von Zufallsvariablen gibt es per se keine Abhängigkeit. Warum branchProbabilities? Es kann in großen Komponenten vorkommen, dass das Verhalten nicht mehr als parametrische Abhängigkeit modelliert werden kann. In einem solchen Fall soll ein stochastisches, durch den Komponentenentwickler abgeschätztes Verhalten erlaubt sein.
• CollectionIteratorAction erlaubt die explizite Spezifikation des Iterierens über einen Collection-Parameter. Diese Action beerbt LoopAction und enthält zusätzlich eine Referenz auf einen (formalen) Parameter aus der Signatur des zum SEFF gehörenden Dienstes. Damit können Situationen wie im QoSA-Beispiel ausgedrückt werden, wo die inneren Elemente einer Collection nicht bei jedem Schleifendurchlauf neu ausgewürfelt werden sollen. Die Modellierung ist analog zu UML Expansion-Nodes.

QoSAnnotations

• Warum Annotationen? Es soll erlaubt sein, an system-externen Schnittstellen und "unfertigen Komponenten" Ausführungszeiten bzw. Ausfallwahrscheinlichenken manuell zu spezifizieren. Für die system-externen Schnittstellen ist dies natürlich notwendig. Für unfertige Komponenten soll dies ermöglichen, auch unfertige Architekturen zu analysieren.
• Diese Spezifikationen muss der Software-Architekt bzw. der QoS-Evaluator liefern. Es besteht bei einer solchen, auf Schätzungen/Messungen aufbauenden Spezifikation von Ausführungszeiten die Gefahr, dass die Werte falsch spezifiziert werden. Dadurch könnte die Entwicklung der Architektur negativ beeinflusst werden, weil Architekturentscheidungen aufgrund falscher Vorhersagen getroffen werden. Daher sollte von diesen Spezifikationen möglichst wenig Gebrauch gemacht werden.
• QoSAnnotations ist ein Container für verschiedene Annotationen. In diesem Containers können später neben manuellen Spezifikationen (Service X dauert 5 Sekunden) auch Anforderungen (Service Y darf max. 3 Sekunden dauern) gehalten werden. Daher der allgemeinere Name "Annotations" anstatt QoSSpezifications.
• Ein System kann mehrere QoSAnnotations haben (containment-Beziehung), damit können für Sensitivitätsanalysen verschiedene Annotationssätze durchanalysiert werden.
• Das qosannotations-Paket wird vom System-Paket inkludiert. Es wird nur von Software-Architekten bzw. QoS-Evaluatoren benutzt und nicht von anderen Rollen.
• Im qosannotations-Paket gibt es SpecifiedExecutionTime (abstrakt), was eine Rolle (provided oder required) sowie eine Signatur referenziert. Konkret gibt es ComponentSpecifiedExecutionTime (für Komponenten, referenziert Assembly-Context) und SystemSpecifiedExecutionTime (referenziert sonst nichts).
• Es bestünde die Möglichkeit, die bisherigen Attribute von z.B. Hardware-Knoten (z.B. processingRate einer ProcessingResource) nun in dieses QoSAnnotations-Paket zu ziehen und diese nicht mehr als Attribute der Knoten zu behalten. Damit wäre die Spezifikation solcher Attribute flexibler und es könnten zum Beispiel leicht neue Arten von Spezifikationen außer Performance und Reliability eingefügt werden, in dem einfach eine neue QoSAnnotation eingeführt wird. Dagegen spricht allerdings, dass das Modell zu komplex wird und Rollen wie der System Deployer auch das qosannotations-Paket kennen müsste. Wir haben uns daher für die "einfache" Variante entschieden, die Attribute von Ressourcen festzulegen (Performance und Reliability) und diese nicht als QoSAnnotationen in das Modell aufzunehmen.

System <-> Allocation

• Problem: System referenziert Allocation, das bedeutet dass das System nicht unabhängig von einer Allocation spezifiziert werden kann.
• Lösung: Assoziationspfeil zwischen System und Allocation umgedreht.

Interface

• DataType wurde aufgesplittet, es gibt nun PrimitiveDataType, CollectionDataType und CompositeDataType. Das erleichtert die Generierung von Code. Bei der Generierung von Code für Collections ist man nun plattformabhängiger, da diese nicht mehr als String (z.B. "int[]") in DataType eingetragen werden müssen. Die primitiven Datentypen könnten aus der CORBA IDL Spezifikation abgeleitet werden.
• CollectionDataType besitzt einen inneren DataType (z.B. char bei einem char[])
• CompositeDataType besteht aus n InnerDeclaration, denn für innere Datentypen muss bei CompositeDataTypes neben dem Typ auch ein Name angegeben werden. Deshalb erbt InnerDeclaration von NamedElement und enthält wiederum einen inneren DataType.

Parameter Model

• Die Klasse ParameterUsage ist nun abstrakt und es gibt eine neue Klasse PrimitiveParameterUsage, die wie CollectionParameterUsage und CompositeParameterUsage von ParameterUsage erbt. Damit ist es jetzt möglich OCL-Constraints an diese Klassen zu schreiben und zu checken, ob Parametercharakterisierungen für die richtigen Arten von Datentypen erstellt wurden (z.B. keine CollectionParameterUsage für einen PrimitiveDataType).
• ParametericParameterUsage gibts es nun nicht mehr. ExternalCallActions enthalten nun direkt ParameterUsages aus dem ParameterPackage, da es keinen wirklichen Unterschied zwischen ParametericParameterUsage und ParameterUsage gibt. Daher entfällt die Verdopplung der Konzepte im SEFF. Das Anhängen an ExternalCallAction anstatt an den SEFF ist konzeptionell sauberer.

Bennenung von Probability Density Function (Parser)

• IntRandomVar -> IntPMF (ist keine RandomVar sondern direkt die Wahrscheinlichkeitverteilung)
• DoublePDF (IntPDF macht keinen Sinn, weil die Domäne immer kontinuierlich ist)

12.12.2006 (Minor changes)

• Throughput und processingRate: Typ von Int auf Double geändert
• CollectionIteratorAction ist nicht mehr Erbe von LoopAction, stattdessen gibt es eine gemeinsame abstrakte Oberklasse. Gemeinsam ist das LoopBehaviour, unterschiedlich ist die Condition bzw. Parameter Spezifikation.
• BranchTransition gesplittet in GuardedBranchTransition und ProbabilisticBranchTransition. Eine für Transitions mit Stoex als Guard die andere mit Wahrscheinlichkeitsverteilungen. OCL hinzugefügt, das testet, dass alle Branches vom selben Typ sind.
• ThinkTime ist eine Zufallsvariable und die ArrivalRate wurde durch die InterArrivalTime ersetzt, die auch eine Zufallsvariable ist

20.12.2006 (Minor changes)

• ScenarioBehaviour and SEFFBahaviour inherit Identifier now (for protected regions in generated code)
• Fixed System inheritance order, GUID creation should work now

04.01.2007 (Internal State & Return Values)

• SetVariableAction neu eingeführt, erbt von AbstractResourceDemandingAction, enthält eine VariableUsage. Diese Action soll verwendet werden um Rückgabewerte bzw. Ausgabeparameter während der Ausführung des SEFFs zu setzen. Das Setzen von Rückgabewerten wird mit dieser neuen Action bewerkstelligt, da das Setzen der Werte in der StopAction u.U. nicht eindeutig wäre. Rückgabewerte könnten z.B. innerhalb eines Branches gesetzt werden, dann wäre bei der StopAction kein eindeutiger Rückgabewert.
• ExternalCallAction enthält nun eine zweite Liste von VariableUsage, um Rückgabewerten von Dienstaufrufen innerhalb des SEFFs eindeutige (referenzierbare) Namen zuzuordnen.
• VariableUsage an BasicComponent. Eine BasicComponent enthält nun eine Liste von VariableUsages. Damit können komponentenweit Konfigurationsparameter oder statische, für alle Clients gleiche Variablen einer Komponente mit Verteilungsfunktionen charakterisiert werden. Es könnten z.B. auch Zustände einer Datenbank mit diesen VariableUsages modelliert werden. Diese VariableUsages müssen vom Komponentenentwickler zunächst mit einem Namen versehen werden und können dann optional mit Default-Werten belegt werden. Software-Architekten bzw. Domänen-Experten können diese Default werden bei ihrer Analyse mit angepassten Werten überschreiben.

13.03.2007 Primitive Type Enum

Der Primitive Type Enum enthält nun zusätzlich den Typ LONG.

13.06.2007 (Heiko)

• CommunicationLinkResourceSpecification enthält nun zusätzlich eine Latency (abgeleitet von RandomVariable) zur Spezifikation der Latenz (Delay bzw. Übertragungsdauer für ein Ping) einer Netzwerkressource.
• AbstractUserActions aus dem UsageModel sind nun auch Entities. (repariert Bug #60)
• Im Usage Model gibt es nun eine neue AbstractUserAction namens Delay. Sie enthält eine DelayTime (abgeleitet von RandomVariable). Damit kann modellieren, dass ein Benutzer zwischen zwei Aufrufen an das System denkt oder wartet. (repariert Bug #40)
• Die QoSAnnotations besitzen jetzt eine Menge von SpecifiedOutputParameterAbstraction (abgeleitet von VariableUsage), mit denen die Ausgabeparameter von systemexternen Dienstaufrufen charakterisiert werden können. Sie referenzieren Role und Signature und können damit eindeutig einer Signature eines Interfaces zugeordnet werden. (repariert Bug #128)
• EntryLevelSystemCalls besitzen jetzt eine zweite Menge von VariableUsages zur Speicherung der Charakterisierung von Ausgabeparameter aus dem System. (repariert Bug #157)
• ProcessingResourceSpecification besitzt nun ein Attribut schedulingPolicy vom Type SchedulingPolicy. Dazu wurde eine entsprechende Enum mit den Werten FCFS, PROCESSOR_SHARING und DELAY eingefügt.
• Eine Menge von OCL Constraints für RDSEFF und UsageModel wurden eingefügt.

15.06.2007 (Heiko, Jens)

Im Branch ModifiedFork wurden die folgenden Änderungen eingebaut:

• Umbenennung der Assoziation linkingresource zu linkingResource_ResourceEnvironment
• CommunicationLinkResourceType erbt jetzt direkt von ResourceType statt ProcessingResourceType
  • dadurch wird verhindert, dass eine LinkResource in einen ResourceContainer eingesetzt werden kann
• BasicComponent enthält jetzt PassiveResourceSpecifications
  • das erlaubt die Modellierung von Semaphoren (und Threadpools) in der Softwarearchitektur
  • in Kombination mit Completions ist die Referenz von ResourceContainern auf PassiveResourceSpecifications überflüssig und wurde entfernt
• ForkActions haben jetzt eine Assoziation zu namens waitingFor zu den forkBehaviours auf die am Ende der Action gewartet wird.
  • das erlaubt die Emulation von Asynchronen Methodenaufrufen
• um die Übergabe von Parametern aus den ForkActions zu modellieren, enthält die ForkAction jetzt eine Menge von VariableUsages die die Zuweisung der Ergebnisse ausdrücken.
  • jedes parallel ausgeführte Verhalten bekommt lesenden Zugriff auf den umliegenden StackFrame. Neue Variablen können gesetzt werden. Wie sie in der Umgebung aufgenommen werden wird von den VariableUsages bestimmt.
  • Dabei dürfen natürlich nur Variablen von Verhalten, welches durch waitingFor referenziert wird.

20.07.2007 (Jens, Steffen, Michael)

Einführung von Units in das PCM

• Erstellung eines Unit Pakets
  • Spezifikation von Basiseinheiten in einem Repository
  • Zusammengesetzte Einheiten
    • Multiplikation
    • Exponenten
  • Alle Elemente die Einheiten haben erben von UnitCarryingElement
    • Einheiten sind optional, da sie z.B. bei Skalaren nicht benötigt werden
    • Der String unitSpecification hält die Spezifikation der Einheit wie sie vom Benutzer eingegeben wurde.
    • Die Assoziation zur Klasse Unit ist transient derived und wird aus der Spezifikation generiert.
• Verwendete Muster
  • Composite
  • Interpreter

Im folgenden werden die Änderungen der Pakete des PCM beschrieben.

• ResourceType
  • Ein ResourceType ist jetzt ein UnitCarryingElement. Dies ist die Einheit, die von dem Typ der Ressource verarbeitet werden kann.

• ResourceEnvironment
  • ProcessingResourceSpecification
    • processingRate (double) und unit (string) umgeändert in eine Referenz zur Klasse ProcessingRate, die von RandomVariable erbt. Sie erlaubt die Spezifikation der Verarbeitungsrate und der Einheit.
  • CommunicationLinkResourceSpecification
    • throughput (double) und unit (string) umgeändert in eine Referenz zur Klasse Throughput, die von RandomVariable erbt. Sie erlaubt die Spezifikation des Durchsatzes und der Einheit.
  • PassiveResourceSpecification
    • capacity (int) in eine eigene Klasse ausgelagert. Diese ist ebenfalls ein UnitCarryingElement.

• StoEx
  • NumericalLiteral ist nun ein UnitCarryingElement
  • Änderung der RandomVariable
    • Umbenennung der 'alten' RandomVariable zu PCMRandomVariable
    • Einführung einer neuen Oberklasse RandomVariable
    • Einfügen einer transient derived (volatile) Association (eReference) von RandomVariable zu Expression
    • Verschieben der specification von PCMRandomVariable zu RandomVariable

• ProbFunction
  • Klasse Unit entfernt
  • ProbFunction ist ein UnitCarryingElement

• Seff
  • unit (string) von ParametricResourceDemand entfernt.

14.08.2007 (Heiko)

• RandomVariable bzw. PCMRandomVariable
  • PassiveResource: enthält nun eine PCMRandomVariable für die Modellierung der Kapazität einer passiven Ressource. Es wird eine Zufallsvariable verwendet, weil der Wert der Kapazität aus einem Komponentenparameter stammen kann und die Zufallsvariable eine Zuweisung über einen Komponentenparameter zulässt. In der Regel ist der Wert allerdings konstant (Integer). Die vorherige Modellierung mit einer VariableUsage war fehlerhaft, da auf keine neue Variable zugewiesen werden muss.
  • SpecifiedExecutionTime aus den QoSAnnotations erbt nun nicht mehr von RandomVariable, sondern enthält nun eine PCMRandomVariable namens specification_SpecifiedExecutionTime.
  • ThinkTime aus dem UsageModel: gelöscht. ClosedWorkload enthält nun direkt eine PCMRandomVariable, der Containment-Link heißt thinkTime_ClosedWorkload
  • InterArrivalTime aus dem UsageModel: gelöscht. OpenWorkload enthält nun direkt eine PCMRandomVariable, der Containment-Link heißt interArrivalTime_OpenWorkload
  • LoopIterations aus dem UsageModel: gelöscht. Loop enthält nun direkt eine PCMRandomVariable, der Containment-Link heißt loopIteration_Loop
  • DelayTime aus dem UsageModel: gelöscht. Delay enthält nun direkt eine PCMRandomVariable, der Containment-Link heißt timeSpecification_Delay
  • LoopIteration aus dem RDSEFF: gelöscht. LoopAction enthält nun direkt eine PCMRandomVariable, der Containment-Link heißt loopIteration_LoopAction
  • BranchCondition aus dem RDSEFF: gelöscht. GuardedBranchTransition enthält nun direkt eine PCMRandomVariable, der Containment-Link heißt branchCondition_GuardedBranchTransition
  • ParametricResourceDemand aus dem RDSEFF erbt nun nicht mehr von PCMRandomVariable, sondern enthält nun eine PCMRandomVariable. Der Containment-Link heißt specification_ParametericResourceDemand.
  • NumberOfReplicas aus dem RDSEFF: gelöscht. ForkedBehaviour enthält nun direkt eine PCMRandomVariable, der Containment-Link heißt numberOfReplicas_ForkedBehaviour
  • VariableCharacterisation aus dem Parameter Package erbt nun nicht mehr von PCMRandomVariable sondern enthält nun eine PCMRandomVariable namens specification_PCMRandomVariable.
  • Throughput aus dem ResourceEnvironment: gelöscht. CommunicationLinkResourceSpecification enthält nun direkt eine PCMRandomVariable für den Durchsatz, der Containment-Link heißt throughput_CommunicationLinkResourceSpecification.
  • Latency aus dem ResourceEnvironment: gelöscht. CommunicationLinkResourceSpecification enthält nun direkt eine PCMRandomVariable für die Latenz, der Containment-Link heißt latency_CommunicationLinkResourceSpecification.
  • ProcessingRate aus dem ResourceEnvironment: gelöscht. ProcessingResourceSpecification enthält nun direkt eine PCMRandomVariable für die Bearbeitungsrate, der Containment-Link heißt processingRate_ProcessingResourceSpecification.

• VariableUsage
  • EntryLevelSystemCall: die enthaltenen Listen von VariableUsages wurden zur Vereinheitlichung in inputParameterUsages_EntryLevelSystemCall und outputParameterUsages_EntryLevelSystemCall umbenannt.
  • SpecifiedOutputParameterAbstraction erbt nun nicht mehr von VariableUsage, sondern enthält nun eine Menge von VariableUsage. Diese modelliert alle Ausgabeparameterabstraktionen zu einer Signatur.
  • AssemblyContext: enthält eine Liste von VariableUsages, deren Referenz nun nach configParameterUsages_AssemblyContext umbenannt wurde. Diese Parametercharakterisierungen sollen vom Software Architekten gesetzt werden und betreffen die technische Domäne. Das sind meist Konfigurationsparameter, daher der Name. Parametercharakterisierungen, die Daten von Nutzern oder Datenbanken ausdrücken, werden von nun an im Usage Model vom Domänenexperten spezifiziert.
  • UsageModel: enhält nun zusätzlich eine Menge von UserData. Diese Klasse referenziert jeweils einen AssemblyContext und enthält eine Menge von VariableUsages namens userDataParameterUsages_UserData. Damit kann der Domänenexperte Nutzerspezifische Komponentenparameter modellieren.
  • SetVariableAction: die enthaltene Liste von VariableUsages wurden zur Vereinheitlichung in localVariableUsages_SetVariableAction umbenannt.
  • ExternalCallAction: die enthaltenen Listen von VariableUsages wurden zur Vereinheitlichung in inputParameterUsages_ExternalCallAction und outputParameterUsages_ExternalCallAction umbenannt.
  • ImplementationComponentType enthält nun eine VariableUsage. Damit modelliert der Komponentenentwickler Komponentenparameter und kann Defaultwerte vorgeben, die vom Software-Architekten in einem AssemblyContext oder vom DomainExpert im UsageModel überschrieben werden können.

• Context
  • ActualAllocation in ComputedAllocation umbenannt.
  • ActualAllocationContext in ComputedAllocationContext umbenannt.
  • ComputedAllocationContext referenziert nun einen AllocationContext.
  • ActualResourceDemand in ResourceDemand umbenannt.
  • ResourceDemand enthält nun eine PCMRandomVariable und erbt nicht mehr davon.
  • Usage in ComputedUsage umbenannt.
  • UsageContext in ComputedUsageContext umbenannt.
  • LoopIteration enthält nun eine PCMRandomVariable und erbt nicht mehr davon.

14.08.2007 (Jens, Steffen)

• Infrastructure/code changes
  • Created Palladio.Wrapper where now all external jars live
  • Removed all external jars from all plugins
  • de.uka.ipd.sdq.dialogs split into several smaller xxx.dialogs plugins to get rid of all the dependencies which were caused by this central pluign
  • renamed sensorfactory -> sensorframework

23.08.2007 (Steffen)

• Moved PCMRandomVariable from StoEx to PCM.core (needed because it need the PCM's parser)
• PassiveResource now inherits Entity, needed to identify the resource

08.01.2008 (Lucia, Klaus)

• Refactoring: split the qosannotations package into performance and reliability annotations (prepared merging of SOFA and PCM)
• Attention: since December 2007 RSA models can only be opened using RSA 7, though some package are still not migrated (eg. Capra)

31.01.2008 (Steffen, Klaus)

• Changed Repository: Component Type Hierarchy: now all component types directly inherit from the abstract entity "InterfaceProvidingRequiringEntity" instead building an inheritance tree.
• ProvidesComponentType no more directly inherits from entity (uses indirect inheritance via InterfaceProvidingRequiringEntity)
• AssemblyContext now associates ("encapsulates") InterfaceProvidingRequiringEntity and no more ProvidesComponentType

08.02.2008 (Lucia, Klaus)

• Refactoring: split the seff package into performance and reliability seffs
  • pcm::seff : SEFF: renamed: SeviceEffectSpecificatio -> AbstractServiceEffectSpecification
    • pcm::seff::core: Actions: deleted: CollectionIteratorAction, VariableUsage, SetVariableAction, AbstractResourceDemandingAction, InternalAction attribut failtureProbability; added: generalization from basic actions to AbstractAction
    • pcm::seff::extensions: Extensions: added: VariableUsage, SetVariableAction, CollectionIteratorAction
      • pcm::seff::extensions::performance : Performance: added: ResourceDemandingAction and basic actions
      • pcm::seff::extensions::reliability: Reliability: added: InternalAction with association "failtureProbability" to PCMRandomVariable

03.03.2008 (Steffen)

• (+) SimuController, Runconfig, Workflow:

Weitergehende Möglichkeiten eingebaut, Abläufe parallel auszuführen. Die Sensititivitätsanalyse nutzt diese Möglichkeiten nun in einer ersten Fassung. Auch der oAW Generator generiert unter Nutzung aller CPU Cores, die die unterliegende Hardware anbietet.

• (+) SimuCom Framework, SimuCom GUI:

SimuCom nutzt nun s.g. SimulationDocks, an dass es seine Simulationen versendet. Dies kann auch Remote geschehen, wenn ein solches Dock irgendwo im Netz also plain OSGi Anwendung läuft. Die GUI von SimuCom ist komplett neu, sie zeigt den Status der Docks an: Welche Docks gibt es, welche sind Busy/Idle, etc...

• (+) Sensorframework:

Effizientes Backend für den Sensorframework File-Provider eingebaut. Das neue Backend verbraucht nun nahezu keinen Hauptspeicher mehr beim speichern der Daten. Alles wird in s.g. Kacheln auf die Platte geschrieben. Der Provider ist dadurch schneller und deutlich flexibler geworden. Limit für Simulationsdaten dürfte damit "nur noch" der verfügbare Plattenplatz sein...

ACHTUNG: Diese Änderung bricht das alte File-Provider Dateiformat. Das Sensorframework kann nach dem Update alte, serialisierte File-Datenquellen nicht mehr einlesen!

08.04.2008 (Steffen)

• Fixed PCM meta model:
  • Removed inheritence of BC and CC from InterfaceProvidingReqEntity
  • Added instead inhertitence of ImplComponentType (which again leads to inheritence of InterfaceProvidingReqEntity)
  • Removed obsolete <<realize1>> and <<realize2>> link (between BC and ImplComponentType, between CC and ImplComponentType)

21.06.2008 (Steffen)

• Base for PCM Release 3.0
• fixed bug in identifier.emx: fixed the ECore Stereotypes (see SVN log for revision 5037).

02.10.2008 (Klaus, Micha, Franz)

• Added SubSystem
  • The new SubSystem inherits from ComposedProvidingRequiringEntity
  • Semantics: Compared to CompositeComponents, SubSystems are allowed to be allocated on multiple nodes. Thus, for System Deployers they are white-box-entities of which sub-components are visible.

22.10.2008 (Klaus, Micha)

• Introduced new "RepositoryComponent" as abstract parent of all component types (ProvidesComponentType, CompleteComponentType, ImplementationComponentType, SubSystem) that can be directly created in a repository. Bugfix of changes from "31.01.2008 (Steffen, Klaus)".
  • Problem to solve: All InterfaceProvingRequiringEntites except System should be composable from repositories.
  • Design alternatives:
    1. Introduce constraint to limit allows classes (exclude System). Not selected due to additional complexity through constraints.
    2. Common superclass that is composed instead (chosen).
    3. Direct composition for all subclasses of RepositoryComponent. Not selected due to breaking changes in code and model; harder to select all components at once.
• Enhanced resource environment / resource access
  • Introduced ResourceRequiredRole to express ResourceDemands of InternalControlFlowAction
  • Introduced ResourceRequiredDelegationConnector to allow delegating resource demands in composed structures (across different levels of software components)
  • Introduced ResourceInterfaceRequiringEntity; composes ResourceRequiredRole; ResourceInterfaceRequiringEntity is a superclass of InterfaceProvidingRequiringEntity
  • ParametricResourceDemand has no longer ProcessingRessourceType; replaced by ResourceRequiredRole (breaking change)

24.10.2008 (Micha, Klaus)

• Made attribute ancestorInterfaces_Interface of Interface derived and transient; fixed typo

07.11.2008 (Klaus, Anne)

• Fixed a MetaModel Bug: A system could be the encapsulated component in an AssemblyContext
  • Changed target of encapsulatedChildComponent... relation of AssemblyContext to RepositoryComponent
  • Made RepositoryComponent inheriting from InterfaceProvidingRequiringEntity so that assembled things always have interfaces/roles
  • Consequently deleted inheritance relations that were doubled by this:
    • From all *ComponentTypes and SubSystem to InterfaceProvidingRequiringEntity, they now indirectly inherit from.
• Renamed association names of *childComponentContext* to *assemblyContext* (around AssemblyContext, which used to be called ChildComponentContext. The renaming of the associations was forgotten when the class itself was renamed)

11.11.2008 (Franz, Klaus)

• + added failure Probability for SpecifiedFailureProbability (EDouble attribute)
• + changed type of FailureProbabilty attribute of InternalAction to EDouble

15.11.2008 PCM 3.0 Release

Attention: This release does not contain the metamodel changes after 21.06.2008 (SVN revision 5037)

• Release tag in the code SVN: PCM_REL_3
• Corresponds to the RSA model as of 21.06.2008 (SVN revision 5037) All changes since that date are not considered in PCM 3.0, but will be incorporated in future releases.

20.11.2008 (Anne)

Nachträge zu 07.11.2008 (Klaus, Anne)

• Renamed all association names of *childComponentContext* to *assemblyContext*
• Renamed association names of *_CompositeAssemblyConnector to *_AssemblyConnector
• Fixed constraints that were broken due to the renaming.

03.12.2008 (Steffen)

• Fixed several incosistent ECore Stereotypes and their tagged values
• Adjusted all PCM Version Numbers to have V4.0 now
• Preparations to regenerate code with Eclipse 3.4

15.07.2009 PCM 3.1 Release

• Release tag in the code SVN: PCM_REL_3.1
• Corresponds to the RSA model as of 16.05.2009 (SVN revision 6775)

16.05.2009 (Franz)

• Introduced new attributes "MTTF", "MTTR" to class pcm::resourceenvironment::ProcessingResourceSpecification
• Introduced new attribute "failureProbability" to class pcm::resourceenvironment::CommunicationLinkResourceSpecification

19.05.2009 (Klaus)

• AbstractBranchTransition is now a NamedElement; removed direct inheritance relation to Identifier

24.07.2009 (Igor)

• Added RetryCount attribute to ExternalCallAction

17.09.2009 (Klaus)

• Added RequiredCharactersation to Interface to enable interfaces to specify variable characterisations. This requirement had been documented before in p. 122. The realised solution differs from the proposed one: Parameters are referenced directly instead of introducing an artificial name.

18.09.2009 (Klaus)

Updated ResourceEnvironment: since connections are bidirectional, from and to are meaningless for LinkingResources:

• renamed fromResourceContainer_LinkingResource to connectedResourceContainers_LinkingResource
• removed toResourceContainer_LinkingResource
• renamed composition between LinkingResource and ResourceEnvironment from linkingResource_ResourceEnvironment to linkingresource linkingResources__ResourceEnvironment
• CommunicationLinkResourceSpecification now inherits from Identifier

05.10.2009 (Klaus)

Added "SubSEFF": SEFFs can now have have internal behaviours to avoid SEFF code and control flow duplication and the need of method inlining.

• new CallAction as abstract parent of ExternalCallAction and InternalCallAction; holds composition of VariableUsage for input and output parameter
• new InternalCallAction to model internal method calls; is a CallAction and associates one ResourceDemandingInternalBehaviour
• new ResourceDemandingInternalBehaviour as capsule of internal behaviour which can be called through internal method calls; "is a" ResourceDemandingBehaviour which existed before
• ResourceDemandingSEFF now composes * ResourceDemandingInternalBehaviour

02.11.2009 (Klaus)

• RSA Model of the PCM is now a RSA 7.5 model
• Changed inheritance of AbstractBranchTransition:
  • - inheritance with NamedElement
  • + inheritance with Entity

02.02.2010 (Klaus)

• ResourceEnvironment is now a NamedEntity (Bug #462)

12.02.2010 (Review in Learning Group, Klaus)

• ExternalCallAction now directly associates a RequiredRole instead of the abstract Role supertype. Associating a general role (implying a possible use of a ProvidedRole) does not make sense.
• Fixed Package imports:
  • Allocation now imports System package not vice versa
  • Removed duplicates

06.04.2010 (Franz, Igor Lankin)

Capabilities for fault tolerance modeling (results of DA Igor) introduced into the meta-model:

• pcm::repository
  • Added an abstract FailureType which is the base class for all failure classes
  • Added an abstract class StopFailureType which derives from FailureType. This class represents failure following the stop-failure semantics.
  • Added two concrete StopFailureType derivatives: ApplicationFailureType and EnvironmentFailureType. Which represent software failures and environment failures respectively. EnvironmentFailureTypes reference excactly one ProccessingResourceType.
  • The repository may specify any number of FailureTypes, therefore an a directed 1:n (composition) association is added from it to the FailureType class.
  • Signatures reference any number of FailureTypes indicating which failures may occur in the interface implementation.

• pcm::seff
  • Internal actions may (optinally) specify failure occurrences of specific types. A FailureOccurrenceDescriptionClass is added for this sake. It references excactly one FailureType and provides a EDouble attribute 'failureProbability'. An InternalAction may reference any number of FailureOccurrenceDescriptions. Two OCL constraints make sure that the sum of all failure probabilities are less or equal 1 and that no failure type is used twice.
  • A new abstract class 'FailureHandlingEntity' is added. It references any number of FailureTypes indicating which failure types are handled.
  • The ExternalCallAction derives from FailureHandlingEntity. It can handle failures by re-execution. The retryCount attribute specifies the maximal re-executions before giving up.
  • The RecoveryBlockAction is introduced as the major failure handling mechanism. It is composed of two or more 'RecoveryBlockAlternativeBehaviour's. One representing a primary control flow and the others representing alternative control flows.
  • As the RecoveryBlockAction can be used in any behaviour it is derived from AbstractInternalControlFlowAction.
  • A RecoveryBlockAlternativeBehaviour specifies a behaviour and therefore derives from ResourceDemandingBehaviour
  • Also RecoveryBlockAlternativeBehaviours are 'FailureHandlingEntity's as they perform the actual failure handling. If one alternative fails the next alternative is executed that can handle that failure type. This implies that the alternatives are ordered, thus a RecoveryBlockAlternativeBehaviour may references its successor.
  • In the RecoveryBlockAction an OCL constraint ensures that the alternatives form a chain (acyclic, connected).

07.04.2010 (Henning)

• Changed the containment relations to be navigable in both directions. In case the target of the relation whad only one containment relation the association was change to -1--x->, in case of more than one containment relatio to -0..1--x->. This enables backward navigation in the model and OCL constraints on elements which were not possible before. The following diagrams and associations were changed:
  • usagemodel::UsageModel_UsageScenario_ScenarioBehaviour
    • UsageModel -> Usage Scenario
    • UsageScenario -> ScenarioBehaviour
    • UsageScenario -> Workload
  • usagemodel::Usage Model
    • ClosedWorkload -> PCMRandomVariable
    • OpenWorkload -> PCMRandomVariable
    • UsageModel -> UsageScenario
    • UsageModel -> UserData
    • UserData -> VariableUsage
  • usagemodel::ScenarioBehaviour
    • EntryLevelSystemCall -> VariableUsage
    • Branch -> BranchTransition
    • BranchTransition -> ScenarioBehaviour
    • ScenarioBehaviour -> AbstractUserAction
    • Loop -> ScenarioBehaviour
  • usagemodel::EntryLEvelSystemCall
    • EntryLevelSystemCall -> VariableUsage
  • seff::SEFF
    • BasicComponent -> ServiceEffectSpecification
    • ResourceDemandingBehaviour -> AbstractAction
  • seff::ResourceDemands
    • ParametricResourceDemand -> PCMRandomVariable
  • seff::RecoveryBlocks
    • RecoveryBlockAction -> RecoveryBlockAlternativeBehaviour
  • seff::Parameter Usage
    • CallAction -out-> VariableUsage
    • CallAction -in-> VariableUsage
  • seff::Loop Behaviour
    • AbstractLoopAction -> ResourceDemandingBehaviour
    • LoopAction -> PCMRandomVariable
  • seff::Fork
    • SynchronisationPoint -> VariableUsage
    • SynchronisationPoint -> ForkedBehaviour
    • ForkAction -> SynchronisationPoint
    • ForkAction -> ForkedBehaviour
  • seff::FailureOccurenceDescription
    • InternalAction -> FailureOccurenceDescription
  • seff::Branch
    • BranchAction -> AbstractBranchTransistion
    • GuardedBranchTransition -> PCMRandomVariable
  • seff::BehaviourOverview
    • ResourceDemandingSEFF -> ResourceDemandingInternalBehaviour
  • seff::Actions
    • SetVariableAction -> VariableUsage
  • resourcetype::Resources
    • ResourceRepository -> ResourceType
  • resourceenvironment::ResourceEnvironment
    • ResourceContainer -> ProcessingResourceSpecification
    • LinkingResource -> CommunicationLinkResourceSpecification
    • ResourceEnvironment -> LinkingResource
    • ResourceEnvironment -> ResourceContainer
    • Allocation -> AllocationContext
  • resourceenvironment::RandomVariableSpecification
    • CommunicationLinkResourceSpecification -> PCMRandomVariable
    • CommunicationLinkResourceSpecification -> PCMRandomVariable
    • ProcessingResourceSpecification -> PCMRandomVariable
  • repository::PassiveResources
    • BasicComponent -> PassiveResource
    • PassiveResource -> PCMRandomVariable
  • repository::Interface
    • Interface -> RequiredCharacterisation
  • repository::FailureTypes
    • Repository -> FailureType
  • repository::Datatype
    • CompositeDataType -> InnerDeclaration
  • qosannotations::QosSpecification
    • System -> QoSAnnotations
    • QoSAnnotations -> SpecifiedQoSAnnotations
    • QoSAnnotations -> SpecifiedOutputParameterAbstraction
    • SpecifiedOutputParameterAbstraction -> VariableUsage
  • parameter::Parameter Package Overview
    • NamespaceReference -> AbstractNamedReference
    • VariableUsage -> AbstractNamedReference
    • VariableUsage -> VariableCharacterisation
  • core::composition::Composition
    • AssemblyContext -> VariableUsage

27.04.2010 (Henning)

• Changed the containment relations to be navigable in both directions:
  • usagemodel::Loop -0..1--> PCMRandomVariable
  • usagemodel::Delay -0..1--> PCMRandomVariable
  • parameter::SpecifiedQoSAnnotation -0..1--> PCMRandomVariable
• Changed relation name because of ambiguity
  • usagemodel::EntryLevelSystemCall -inputParameterUsage-> VariableUsage: Renamed container part of relation to end in InputParameterUsage and not in VariableUsage

04.05.2010 (Henning)

Design Rationale

• Introduced variable characterisations to interfaces. Data types are now carrying those variable characterisations which become part of the contract of components. Before, variable characterisations were implicit assumptions of components (SEFFs) which were not explicitly exposed in interfaces. Now, it can be checked whether all variable characterisations are present when calling a service (ExternalCallAction) and a SEFF can rely on that information internally. The new models semantics can be checked statically.
  • Design alternatives:
    • Characterise single parameters from an interface (characterisations are fixed for a certain interface but can change when reusing a data type)
    • Characterise data types (when reusing the data type, the variable characterisations are fixed; transitively, the characterisations are fixed for interfaces) selected solution
      • Pro:
        • Eases passing of data accross multiple components;
        • During reverse engineering consistent variable characterisations per data type are easier to determine by heuristics
      • Con:
        • Not all characterisations are performance-relevant for every component
        • Might imply overhead for specifying characterisations which are not used in a certain component.
• Variable Charactersations are no more fixed to a enum defined at the model level. Instead, they can be extended at the model level. Variable Charactersiation now also have a data type associated.
  • Pro:
    • Explicit data type allows dynamic type inference in StoEx
    • New characterisations (e.g. entropy) can be realised
    • Semantics per variable characterisation can be more precise (no more bending of semantics of enum-defined characterisations)
  • Con:
    • Increased complexity of StoEx editors etc. cannot rely on a fixed number of characterisations any more. A default repository for previously existing variable characterisations is recommended (VALUE, BYTESIZE, NoE, STRUCTURE, ...).
  • Remark: Complexity for solvers and simulation: The presence of expected variable characterisation (e.g. Bytesize for data transferred via network; Number of Elements declaration for CollectionIterator) must be checked prior to analysis (argument also applies to previous realisation in the PCM).

Changes in Detail

Semantic: -: deleted, o:changed, +:added

Model Elements (two-sided navigation):

• + PCMRandomVariable: loop_LoopIteration
• + PCMRandomVariable: delay_TimeSpecification
• + PCMRandomVariable: specifiedQoSAnnotation_SpecifiedExecutionTime
• + PCMRandomVariable: variableCharacterisation_Specification

Model Elements (characterisation):

• - CharacterizationDefinition
• - Repository: characterisationDefinitions
• - Interface: requiredCharacterisations
• o ImplementationComponentType: componentParameterUsage_ImplementationComponentType -> componentParameter_ImplementationComponentType
• + DataType: directlyAvailableCharacterisationDefinitions_Datatype
• o CollectionDataType: innerType_CollectionDataType -> dataType_InnerCollectionDataType
• o VarableUsage -> SetVariable
• - VariableCharacterisationType
• o repository.Parameter -> parameters.Variable
• - PrimitiveDataType: type
• o CollectionDataType: innerType_CollectionDataType -> dataType_InnerCollectionDataType
• - CollectionDataType: Entity
• - CompositeDataType: Entity
• - CompositeDataType: parentType_CompositeDataType
• - CompositeDataType: compositeDataType_InnerDeclaration
• + CompositeDataType: 0..1 compositeDataType_Variable -* - 1..* members_CompositeDataType -> Variable
• - InnerDeclaration (formerly corresponding to Variable; replaced by Members_CompositeDataType to define inner data type)
• + CharacterisationDefinition
• + CharacterisationDefinition: Entity
• + CharacterisationDefinition: description
• + CharacterisationDefinition: valueType
• + Repository: 1 repository_CharacterisationDefinition -* - * characterisationDefinitions ->
• + DataType: -* - availableCharacterisationDefinitions_Datatype ->
• - CharacterisedVariable: characterisationType
• + CharacterisedVariable: -* - 1 variable -> Variable
• + CharacterisedVariable -* - 1 characterisationDefinition -> CharacterisationDefinition

Diagrams:

• + Datatype_Characterisation

Further Changes:

• DataType.InnerType_CollectionDataType --> DataType.DataType_InnerCollectionDataType
• Signature_Parameter --> OperationSignature__Variable
• Signature --> OperationSignature
• Parameter.ParameterName --> Variable.EntityName
• CharacterisedVariable.getCharacterisationType().getLiteral() has to be replaced with CharacterisedVariable.getCharacterisationDefinition().getEntityName()
• ParameterPackage.eINSTANCE.getVariableUsage_NamedReference_VariableUsage() --> ParameterPackage.eINSTANCE.getVariableSetter_Variable__SetVariable()
• AbstractNamedReference --> CharacterisedVariable (If not affecting the StoEx)

Nachträge (vergessene Aspakte)

• Modifier von Parametern in Signaturen gibt es nicht mehr. Standardsemantik: Eingabeparameter sind INOUT, Ausgabeparameter sind OUT.

22.05.2010 (Franz)

Reliability-specific changes:

• deleted reference from pcm::seff::failureOccurrenceDescription to pcm::seff::FailureType
• created new reference from pcm::seff::failureOccurrenceDescription to pcm::seff:ApplicationFailureType
• renamed pcm::seff::InternalAction.internalAction_failureOccurrenceDescription to pcm::seff::InternalAction.failureOccurrenceDescriptions
• renamed pcm::seff::FailureHandlingEntity.failuretype to pcm::seff::FailureHandlingEntity.failureTypes

25.05.2010 (Benjamin)

New Diagrams for the modeling of the event infrastructures

• repository::InterfacesAndSignatures added
• seff::EmitEventAction added
• core::composition::AssemblyEventConnector
• core::composition::EventDelegation

Modell changes for event infrastructures

• repository:Interface -> removed ancestorInterfaces_Interface association to itself
• repository:OperationInterface added and extends relationship to Interface added
• repository:OperationSignature added and extends relationship to Signature added
• repository:Interface <>-> Signature moved to OperationInterface <>-> OperationSignature and aligned to naming conventions ("interface__OperationSignature" instead of "interface_Signature" and "signatures__OperationInterface" instead of "signatures__Interface")
• repository:Signature extends relationship to Entity added and Attribut serviceName removed
• repository:Signature <>-> Variable moved to OperationSignature <>-> Variable and aligned to naming conventions ("operationSignature__Variable" instead of "signature_Parameter" and "parameters__OperationSignature" instead of "parameters__Signature")
• repository:Signature changed to abstract = true
• repository:Interface changed to abstract = true
• repository:Signature -> DataType (returnType) moved to OperationSignature <>-> DataType and aligned to naming conventions ("returnType__OperationSignature" instead of "returntype__Signature")
• repository:EventType class created and extends relatonship to Signature added
• repository:EventGroup class created and extends relatonship to Interface added
• repository:EventGroup 1 <>-> * EventType added
• repository:EventType 0..1 -> 1 Variable added
• repository:ProvidedRole -> Interface moved to ProvidedRole -> OperationInterface and aligned to naming conventions ("providedRoles__OperationInterface" instead of "providedRoles__Interface")
• repository:RequiredRole -> Interface moved to RequiredRole -> OperationInterface and aligned to naming conventions ("requiredRoles__OperationInterface" instead of "requiredRoles__Interface")
• repository:SinkRole with extension relationship to Role added
• repository:SourceRole with extension relationship to Role added
• repository:SourceRole * -> 1 EventGroup added
• repository:SinkRole * -> 1 EventGroup added
• seff:ExternalCallAction -> Signature assoziation moved to ExternalCallAction -> OperationSignature
• seff:CallReturnAction added and extending CallAction.
• seff:CallAction <>-in-> SetVariable moved to CallReturnAction <>-in-> SetVariable
• seff:CallReturnAction "callAction_out_VariableUsage" renamed to "callReturnAction_SetVariable"
• seff:CallReturnAction "outputVariableUsages_ExternalCallAction" renamed to "setVariableReturns__CallReturnAction"
• seff:CallAction "inputParameterUsages_ExternalCallAction" renamed to "setVariableInputs__CallAction"
• seff:CallAction "callAction_in_VariableUsage" renamed to "callAction__SetVariable"
• seff:EmitEventAction added and extending CallAction
• seff:EmitEventAction * -> 1 EventType
• seff:EmitEventAction * -> 1 SourceRole
• core::composition::AssemblyEventConnector extending Connector added
• core::composition::AssemblyEventConnector -> SinkRole added
• core::composition::AssemblyEventConnector -> SourceRole added
• core::composition::AssemblyEventConnector *->1 AssemblyContext (sinkAssemblyContext__AssemblyEventConnector) added
• core::composition::AssemblyEventConnector *->1 AssemblyContext (sourceAssemblyContext__AssemblyEventConnector) added
• core::composition::AssemblyConnector -to-> AssemblyContext (0..1)->(1) instead of (1)->(1)
• core::composition::AssemblyConnector -from-> AssemblyContext (0..1)->(1) instead of (1)->(1)
• core::composition::ComposedStructure <>-> AssemblyEventConnector added
• core::composition::SourceDelegationConnector added and extends DelegationConnector
• core::composition::SourceDelegationConnector ->(1) innerSourceRole__SourceRole added
• core::composition::SourceDelegationConnector ->(1) outerSourceRole__SourceRole added
• core::composition::SourceDelegationConnector ->(1) assemblyContext__SourceDelegationConnector added
• core::composition::SinkDelegationConnector added and extends DelegationConnector
• core::composition::SinkDelegationConnector ->(1) innerSinkRole__SinkRole added
• core::composition::SinkDelegationConnector ->(1) outerSinkRole__SinkRole added
• core::composition::SinkDelegationConnector ->(1) assemblyContext__SinkDelegationConnector added

Meta Model corrections

• parameter::Variable rolled back the abstract = true attribute to false
• repository::Interface relationship parentInterace__Interface renamed to parentInteraces__Interface

Adoptations for Resources and Infrastructures (not related to events)

• repository:ResourceInterface added and extends relationship to Interface added
• repository:ResourceSignature added and extends relationship to Signature added
• repository:InfrastructureInterface added and extends relationship to Interface added
• repository:InfrastructureSignature added and extends relationship to Signature added
• repository:Variable -> DataType renamed assoziation end dataType_Variable to dataType__Variable
• repository:OperationSignature -> DataType renamed assoziation end returntype__Signature to returnType__OperationSignature
• repository:OperationSignature assoziation to Variables changed from (1)<>->(*) to (0..1)<>->(*)
• repository:ResourceSignature (0..1)<>->(1) Variables added
• repository:InfrastructureSignature (0..1)<>->(*) Variables added

Adopted OCL Constraints

• repository::Interface OCL Constraint "SignaturesHaveToBeUniqueForAnInterface" moved to OperationInterface and variables fixed
• seff::ExternalCallAction OCL Constraint "SignatureBelongsToRole" variable fixed
• repository:OCL Constraint: "Parameter Names Have To Be Unique For A Signature" moved from Signature to OperationSignature and names adopted as well as parameterName to entityName

Further Changes

• ExternalCallAction: OutputVariableUsages_ExternalCallAction --> SetVariableReturns__CallReturnAction

26.05.2010 (Benjamin during Coding Night)

Purpose: Introducing an abstraction for ProvidedRole and RequiredRole plus fixing some naming conventions in hennings changes

• repository::ProvidedRole renamed to OperationProvidedRole
• repository::RequiredRole renamed to OperationRequiredRole
• repository::Abstract ProvidedRole extending Role added
• repository::Abstract RequiredRole extending Role added
• repository::OperationProvidedRole extension to ProvidedRole added
• repository::OperationRequiredRole extension to RequiredRole added
• repository::SinkRole extending ProvidedRole
• repository::SourceRole extending RequiredRole
• repository::providedInterface__ProvidedRole renamed to providedInterface__OperationProvidedRole
• repository::requiredInterface__RequiredRole renamed to requiredInterface__OperationRequiredRole
• core::entity:: InterfaceRequiringEntity <>-> now pointing to the abstract RequiredRole
• core::entity:: InterfaceProvidingEntity <>-> now pointing to the abstract ProvidedRole
• parameter::SetVariable variableUsage_VariableCharacterisation renamed to setVariable__VariableCharacterisation
• parameter::SetVariable variable_VariableUsage renamed to variable__SetVariable
• parameter::SetVariable setVariableAction_VariableUsage renamed to setVariableAction__SetVariable
• parameter::SetVariable assemblyContext_VariableUsage renamed to assemblyContext__SetVariable
• parameter::SetVariable synchronisationPoint_VariableUsage renamed to synchronisationPoint__SetVariable
• parameter::SetVariable userData_VariableUsage renamed to userData__SetVariable
• parameter::SetVariable variableCharacterisation_VariableUsage renamed to variableCharacterisation__SetVariable

26.05.2010 (Anne)

• Fixed Metamodel error: fixed accidental deletion of the parameter in the CollectionIteratorAction by restoring that association.

(revision 9136)

TODOs noticed for Hennings refactorings:

• AbstractNamedReference (from StoEx) not used anymore for SetVariable (VariableUsage). Does that affect the StoExParser etc.?
• CollectionIteratorAction now undefined. TODO: Need to state what characterisation is used for determining the number of iterations, and what characterisations should only be evaluated once per iteration.

28.05.2010 (Anne, Chris, Franz, Klaus, Micha, Michael)

Changes after today's model review (revision 9177):

• SetVariable is now VariableSetter (rename)
• VariablerSetter (former SetVariable) associates the CharacterisedVariable instead of Variable (otherwise no connection to the StoEx Variables would exist).
• To avoid naming confusion with the PCM::Variable, StoEx::Variable was renamed to StoEx::StoExVariable

---

Temporary Rollback (revision 9179):

• Removed CharacterisationDefinition and replaced by reintroduced fixed VariableCharactersationType (STRUCTURE, VALUE, NoE, etc.)
• DataType and CharacterisedVariable now associate VariableCharactersationType instead of CharacterisationDefinition

31.05.2010 (Micha)

Fixed OCL constraints due to prior changes; minor renamings (revision 9195):

• Renamed ResourceRequiredRole.requiredInterface_ResourceRequiredRole to requiredInterface__ResourceRequiredRole
• Renamed ResourceRequiredRole.resourceRequiringEntity_ResourceRequiredRole to resourceRequiringEntity__ResourceRequiredRole
• Renamed RequiredRole.requiringEntity_RequiredRole to requiringEntity__RequiredRole
• Renamed ProvidedRole.providingEntity_ProvidedRole to providingEntity__ProvidedRole
• Renamed AssemblyConnector.providedRole_AssemblyConnector to providedRole__AssemblyConnector
• Renamed AssemblyConnector.requiredRole_AssemblyConnector to requiredRole__AssemblyConnector

Revision 9196:

• Fixed identifier OCL constraint
• Set type of VariableCharacterisation to VariableCharacterisationType

02.06.2010 (Benjamin)

Documentation added to the new elements introduced by the changes of 25.05.2010 (Benjamin). No meta model elements have been changed this time. (revision 9201)

03.06.2010 (Micha)

Renamed pcm::repository::CollectionDataType reference dataType_InnerCollectionDataType to innerDataType__CollectionDataType (revision 9204)

08.06.2010 (Benjamin)

(Revision 9226)

Rational
EntryLevelSystemCalls are for now only supported for calls to operations. For this the EntryLevelSystemCall now points to the concrete OperationSignature instead of the abstract Signature

Model
pcm::usagemodel::EntryLevelSystemCall association signature_EntryLevelSystemCall moved from Signature to OperationSignature and adopted naming conventions to "operationSignature__EntryLevelSystemCall"

Diagramm
pcm::usagemodel::EntryLevelSystemCall placed OperationInterface instead of Interface in the diagram

08.06.2010 (Micha)

(Revision 9227)

Further changes w.r.t. Variables:

• Removed VariableCharacterisation
• VariableSetter now contains PCMRandomVariable
• Renamed CharacterisedVariable to VariableCharacteristic
• Variable contains 1..* VariableCharacteristics
• OperationSignature now references Variable for return type

Renamings to make metamodel more consistent:

• Package Seff:
  • CollectionIteratorAction.variable_CollectionIteratorAction --> CollectionIteratorAction.variable__CollectionIteratorAction
  • Made CollectionIteratorAction.variable_CollectionIteratorAction public
  • SynchronisationPoint.outputParameterUsage_SynchronisationPoint --> SynchronisationPoint.outputVariableSetters__SynchronisationPoint
  • CallAction.setVariableInputs__CallAction --> CallAction.variableSetterInputs__CallAction
  • CallReturnAction.setVariableReturns__CallReturnAction --> CallReturnAction.variableSetterReturns__CallReturnAction
• Package Parameter:
  • VariableSetter association names now consistent
  • Variable.implementationComponentType_Variable --> Variable.implementationComponentType__Variable
  • Variable.compositeDataType_Variable --> Variable.compositeDataType__Variable
• Package Repository:
  • ImplementationComponentType.componentParameter_ImplementationComponentType --> ImplementationComponentType.componentParameter__ImplementationComponentType
  • DataType.characterisationDefinitions_Datatype --> DataType.characterisationDefinitions__Datatype
  • CompositeDataType.members_CompositeDataType --> CompositeDataType.members__CompositeDataType
  • ResourceSignature.parmeter__ResourceSignature --> ResourceSignature.parameter__ResourceSignature
  • InfrastructureInterface.infrastructureSignatures_InfrastructureInterface --> InfrastructureInterface.infrastructureSignatures__InfrastructureInterface
• Package Core:
  • AssemblyContext.configParameterUsages_AssemblyContext --> AssemblyContext.configVariableSetters__AssemblyContext
• Package UsageModel:
  • EntryLevelSystemCall.inputParameterUsages_EntryLevelSystemCall --> EntryLevelSystemCall.inputVariableSetters__EntryLevelSystemCall
  • EntryLevelSystemCall.outputParameterUsages_EntryLevelSystemCall --> EntryLevelSystemCall.outputVariableSetters__EntryLevelSystemCall
  • UserData.userDataParameterUsages_UserData --> UserData.userDataVariableSetters__UserData

09.06.2010 (Micha)

(revision 9269)

Rollback of all changes to revision 8918

10.06.2010 (Benjamin)

Re-Introduced the previous changes into the rolled back meta model.

Rational
First class Entities for event based asynchronous communications are introduced to model this type of component interaction. Mainly, this affects the infrastructure for interface and signature. The changes are designed in alignment with changes for Infrastructure and Resource calls that will be introduced in the near future. Now, there is a separation between concrete types of Interfaces and Signatures which are Operations, Resources, Infrastructure and Events. EntryLevelSystemCalls are for now only supported for operations.

New and adopted Diagrams for the modeling of the event infrastructures

• repository::InterfacesAndSignatures added
• seff::EmitEventAction added
• core::composition::AssemblyEventConnector
• core::composition::EventDelegation
• usagemodel::EntryLevelSystemCall placed OperationInterface instead of Interface in the diagram

Modell changes for event infrastructures

• repository:Interface -> removed ancestorInterfaces_Interface association to itself
• repository:OperationInterface added and extends relationship to Interface added
• repository:OperationSignature added and extends relationship to Signature added
• repository:Interface <>-> Signature moved to OperationInterface <>-> OperationSignature and aligned to naming conventions ("interface__OperationSignature" instead of "interface_Signature" and "signatures__OperationInterface" instead of "signatures__Interface")
• repository:Signature extends relationship to Entity added and Attribut serviceName removed
• repository:Signature <>-> Parameter moved to OperationSignature <>-> Parameter and aligned to naming conventions ("operationSignature__Parameter" instead of "signature_Parameter" and "parameters__OperationSignature" instead of "parameters__Signature")
• repository:Signature changed to abstract = true
• repository:Interface changed to abstract = true
• repository:Signature -> DataType (returnType) moved to OperationSignature <>-> DataType and aligned to naming conventions ("returnType__OperationSignature" instead of "returntype__Signature")
• repository:EventType class created and extends relatonship to Signature added
• repository:EventGroup class created and extends relatonship to Interface added
• repository:EventGroup 1 <>-> * EventType added
• repository:EventType 0..1 -> 1 Variable added
• repository::ProvidedRole renamed to OperationProvidedRole
• repository::RequiredRole renamed to OperationRequiredRole
• repository::Abstract ProvidedRole extending Role added
• repository::Abstract RequiredRole extending Role added
• repository::OperationProvidedRole extension to ProvidedRole added
• repository::OperationRequiredRole extension to RequiredRole added
• repository:ProvidedRole -> Interface moved to OperationProvidedRole -> OperationInterface and aligned to naming conventions ("providedRoles__OperationInterface" instead of "providedRoles__Interface")
• repository:RequiredRole -> Interface moved to OperationRequiredRole -> OperationInterface and aligned to naming conventions ("requiredRoles__OperationInterface" instead of "requiredRoles__Interface")
• repository:SinkRole with extension relationship to ProvidedRole added
• repository:SourceRole with extension relationship to RequiredRole added
• repository:SourceRole * -> 1 EventGroup added
• repository:SinkRole * -> 1 EventGroup added
• repository::providedInterface__ProvidedRole renamed to providedInterface__OperationProvidedRole
• repository::requiredInterface__RequiredRole renamed to requiredInterface__OperationRequiredRole
• seff:ExternalCallAction -> Signature assoziation moved to ExternalCallAction -> OperationSignature
• seff:CallReturnAction added and extending CallAction.
• seff:CallAction <>-out-> SetVariable moved to CallReturnAction <>-out-> SetVariable
• seff:CallReturnAction "callAction_out_VariableUsage" renamed to "callReturnAction__VariableUsage"
• seff:CallReturnAction "outputVariableUsages_ExternalCallAction" renamed to "returnVariableUsage__CallReturnAction"
• seff:CallAction "inputParameterUsages_ExternalCallAction" renamed to "inputVariableUsages__CallAction"
• seff:CallAction "callAction_in_VariableUsage" renamed to "callAction__VariableUsage"
• seff:EmitEventAction added and extending CallAction and AbstractAction
• seff:EmitEventAction * -> 1 EventType
• seff:EmitEventAction * -> 1 SourceRole
• core::composition::AssemblyEventConnector extending Connector added
• core::composition::AssemblyEventConnector (*)->(1) SinkRole added
• core::composition::AssemblyEventConnector (*)->(1) SourceRole added
• core::composition::AssemblyEventConnector (*)->(1) AssemblyContext (sinkAssemblyContext__AssemblyEventConnector) added
• core::composition::AssemblyEventConnector (*)->(1) AssemblyContext (sourceAssemblyContext__AssemblyEventConnector) added
• core::composition::ComposedStructure <>-> AssemblyEventConnector added
• core::composition::AssemblyConnector -to-> AssemblyContext (0..1)->(1) instead of (1)->(1)
• core::composition::AssemblyConnector -from-> AssemblyContext (0..1)->(1) instead of (1)->(1)
• core::composition::SourceDelegationConnector added and extends DelegationConnector
• core::composition::SourceDelegationConnector ->(1) innerSourceRole__SourceRole added
• core::composition::SourceDelegationConnector ->(1) outerSourceRole__SourceRole added
• core::composition::SourceDelegationConnector ->(1) assemblyContext__SourceDelegationConnector added
• core::composition::ComposedStructure <>-> SourceDelegationConnector added
• core::composition::SinkDelegationConnector added and extends DelegationConnector
• core::composition::SinkDelegationConnector ->(1) innerSinkRole__SinkRole added
• core::composition::SinkDelegationConnector ->(1) outerSinkRole__SinkRole added
• core::composition::SinkDelegationConnector ->(1) assemblyContext__SinkDelegationConnector added
• core::composition::ComposedStructure <>-> SinkDelegationConnector added
• core::entity:: InterfaceRequiringEntity <>-> now pointing to the abstract RequiredRole
• core::entity:: InterfaceProvidingEntity <>-> now pointing to the abstract ProvidedRole
• pcm::usagemodel::EntryLevelSystemCall association signature_EntryLevelSystemCall moved from Signature to OperationSignature and adopted naming conventions to "operationSignature__EntryLevelSystemCall"

Meta Model corrections

• repository::Interface relationship parentInterace__Interface renamed to parentInteraces__Interface and the name "<<extends2>>" of the relation removed

Adoptations for Resources and Infrastructures (not related to events)

• repository:ResourceInterface added and extends relationship to Interface added
• repository:ResourceSignature added and extends relationship to Signature added
• repository:InfrastructureInterface added and extends relationship to Interface added
• repository:InfrastructureSignature added and extends relationship to Signature added
• repository:OperationSignature -> DataType renamed assoziation end returntype__Signature to returnType__OperationSignature
• repository:OperationSignature assoziation to Parameter changed from (1)<>->(*) to (0..1)<>->(*)
• repository:ResourceSignature (0..1)<>->(1) Parameter added
• repository:InfrastructureSignature (0..1)<>->(*) Parameter added

Adopted OCL Constraints

• repository::Interface OCL Constraint "SignaturesHaveToBeUniqueForAnInterface" moved to OperationInterface and variables fixed
• seff::ExternalCallAction OCL Constraint "SignatureBelongsToRole" variable fixed
• repository:OCL Constraint: "Parameter Names Have To Be Unique For A Signature" moved from Signature to OperationSignature and names adopted as well as parameterName to entityName

11.06.2010 (Benjamin)

Fixed Association from VariableUsage to Named Reference pcm::parameter:: variableUsage__NamedReference <>-> namedReference__VariableUsage

11.06.2010 (Micha)

(revision 9275)

Removed bidirectional navigation AbstractNamedReference - VariableUsage (stoex should not be dependent from pcm)

14.06.2010 (Micha)

(revision 9314)

Changed cardinality of infrastructureSignature__Parameter from 1 to 0..1

16.06.2010 (Benjamin)

(Revision 9333)

Fixed OCL Constraints

• pcm::repository::BasiComponent OCL Constraint "ProvideSameInterfaces As Implementation Type" fixed
• pcm::repository::BasiComponent OCL Constraint "Require Same Interfaces As Implementation Type" fixed
• pcm::repository::CompositeComponent OCL Constraint "ProvideSameInterfaces" fixed
• pcm::repository::CompositeComponent OCL Constraint "RequireSameInterfaces" fixed

16.06.2010 (Benjamin)

(Revision 9341)

Fixed OCL Constraints

• pcm::core::composition::AssemblyConnector OCL Constraint "AssemblyConnectorsReferencedInterfacesMustMatch" fixed and bug to improve this constrained added to bugzilla: https://sdqweb.ipd.uka.de/bugzilla/show_bug.cgi?id=609

30.06.2010 (Anne)

(Revision 9449)

• changes threshold values in OCL constraint (AllProbabilisticBranchProbabilitiesMustSumUpTo1) so that now probability sums between 0.9999 and 1.0001 are ok. This probably was introduced due to rounding errors in e.g. the dependency solver(?).

12.07.2010 (Micha)

(Revision 9557)

• Removed private attribute variableUsage__NamedReference from StoEX AbstractNamedReference

21.07.2010 (Benjamin)

(Revision 9653)

• Modified xml file to change inheritence order of the EmitEventAction

20.09.2010 (Anne)

(Revision 10239, RSA Model only)

• Added OCL constraint on EntryLevelSystemCall
  • EntryLevelSystemCallMustReferenceProvidedRoleOfASystem
  • self.providedRole_EntryLevelSystemCall.providingEntity_ProvidedRole.oclIsTypeOf(System)
  • Reason: The transformation to SimuCom code assumes that the entity that offers the OperationProvidedRole of the EntryLevelSystem call is a System (see e.g. m2t_transforms::sim::usage::SystemVariableDecl).

05.11.2010 (Franz)

(Revision pcm.emx=10470)

• Refactored QosAnnotations
  • Introduced new abstract class pcm::qosannotations::performance::SpecifiedExecutionTime, which inherits from SpecifiedQoSAnnotation, and is the new base class for ComponentSpecifiedExecutionTime and SystemSpecifiedExecutionTime
  • Moved property specification_SpecifiedExecutionTime from SpecifiedQoSAnnotation to SpecifiedExecutionTime
  • Added OCL constraint SystemSpecifiedExecutionTimeMustReferenceRequiredRoleOdASystem to SystemSpecifiedExecutionTime
  • Renamed SpecifiedFailureProbability to SpecifiedReliabilityAnnotation; further changes to this class:
    • Removed property failureProbability
    • Removed OCL constraint EnsureValidParameterRange
    • Added property failureOccurrenceDescriptions_SpecifiedReliabilityAnnotation
    • Added OCL constraint SpecifiedReliabilityAnnotationMustReferenceRequiredRoleOfASystem
• Refactored Reliability-related parts
  • Created new package pcm::reliability
    • Moved from pcm::repository to pcm::reliability: FailureType, StopFailureType, ApplicationFailureType, EnvironmentFailureType
    • Moved FailureOccurrenceDescription from pcm::seff to pcm::reliability
    • Renamed property failureType of FailureOccurrenceDescription to applicationFailureType_FailureOccurrenceDescription
    • Renamed property failureOccurrenceDescriptions of InternalAction to failureOccurrenceDescriptions_InternalAction
    • Renamed property failureTypes of pcm::repository::Repository to failureTypes_Repository
    • Renamed property prosessingresourcetype of EnvironmentFailureType to processingResourceType_EnvironmentFailureType
  • Created new package pcm::seff::reliability
    • Moved from pcm::seff to pcm::seff::reliability: FailureHandlingEntity, RecoveryBlockAction, RecoveryBlockAlternativeBehaviour
    • Let FailureHandlingEntity inherit from Entity
    • Renamed property failureTypes of FailureHandlingEntity to failureTypes_FailureHandlingEntity
    • Renamed property recoveryBlockalternativeBehaviours of RecoveryBlockAction to recoveryBlockAlternativeBehaviours_RecoveryBlockAction
    • Renamed property nextAlternative of RecoveryBlockAlternativeBehaviour to nextAlternative_RecoveryBlockAlternativeBehaviour

16.12.2010 (Henning)

(Revision 10669)

New:

• pcm::entity::ResourceProvidedRole
• pcm::entity::ResourceInterfaceProvidingEntity
• pcm::entity::ResourceInterfaceRequiringEntity
• pcm::entity::ResourceInterfaceProvidingRequiringEntity
• pcm::repository::InfrastructureProvidedRole
• pcm::repository::InfrastructureRequiredRole
• pcm::core::composition::AssemblyInfrastructureConnector
• pcm::core::composition::ProvidedInfrastructureDelegationConnector
• pcm::core::composition::RequiredInfrastructureDelegationConnector
• pcm::core::composition::RequiredResourceDelegationConnector
• pcm::repository::ComponentType
• pcm::seff::performance::InfrastructureCall
• pcm::seff::performance::ResourceCall

• pcm::repository::InfrastructureInterface -> pcm::repository::InfrastructureSignature
• pcm::repository::InfrastructureProvidedRole -> pcm::repository::InfrastructureInterface
• pcm::repository::InfrastructureRequiredRole -> pcm::repository::InfrastructureInterface
• pcm::core::composition::AssemblyInfrastructureConnector -> pcm::repository::InfrastructureProvidedRole
• pcm::core::composition::AssemblyInfrastructureConnector -> pcm::repository::InfrastructureRequiredRole
• pcm::core::composition::AssemblyInfrastructureConnector -> (providingAssemblycontext__AssemblyInfrastructureConnector) pcm::core::composition::AssemblyContext
• pcm::core::composition::AssemblyInfrastructureConnector -> (requiringAssemblycontext__AssemblyInfrastructureConnector) pcm::core::composition::AssemblyContext
• pcm::core::composition::ComposedStructure <>-> pcm::core::composition::AssemblyInfrastructureConnector
• pcm::core::composition::ComposedStructure <>-> pcm::core::composition::ProvidedInfrastructureDelegationConnector
• pcm::core::composition::ComposedStructure <>-> pcm::core::composition::RequiredInfrastructureDelegationConnector
• pcm::core::composition::ProvidedInfrastructureDelegationConnector -> (innerProvidedRole__ProvidedInfrastructureDelegationConnector) pcm::repository::InfrastructureProvidedRole
• pcm::core::composition::ProvidedInfrastructureDelegationConnector -> (outerProvidedRole__ProvidedInfrastructureDelegationConnector) pcm::repository::InfrastructureProvidedRole
• pcm::core::composition::ProvidedInfrastructureDelegationConnector -> pcm::core::composition::AssemblyContext
• pcm::core::composition::RequiredInfrastructureDelegationConnector -> (innerRequiredRole__RequiredInfrastructureDelegationConnector) pcm::repository::InfrastructureRequiredRole
• pcm::core::composition::RequiredInfrastructureDelegationConnector -> (outerRequiredRole__RequiredInfrastructureDelegationConnector) pcm::repository::InfrastructureRequiredRole
• pcm::core::composition::RequiredInfrastructureDelegationConnector -> pcm::core::composition::AssemblyContext
• pcm::core::composition::ComposedStructure <>-> RequiredResourceDelegationConnector
• pcm::core::composition::RequiredResourceDelegationConnector -> (innerRequiredRole__RequiredResourceDelegationConnector) pcm::repository::ResourceRequiredRole
• pcm::core::composition::RequiredResourceDelegationConnector -> (outerRequiredRole__RequiredResourceDelegationConnector) pcm::repository::ResourceRequiredRole
• pcm::core::composition::RequiredResourceDelegationConnector -> pcm::core::composition::AssemblyContext
• pcm::resourecetype::ResourceType *--*> pcm:repository::ResourceProvidedRole
• pcm::repository::ImplementationComponentType --1-> componentType
• pcm::seff::AbstractInternalControlFlowAction <>-> pcm::seff::performance::InfrastructureCall
• pcm::seff::performance::InfrastructureCall -|> pcm::seff::CallAction
• pcm::seff::performance::InfrastructureCall -> pcm::core::PCMRandomVariable
• pcm::seff::performance::InfrastructureCall -> pcm::repository::InfrastructureProvidedRole
• pcm::seff::performance::InfrastructureCall -> pcm::repository::InfrastructureSignature
• pcm::seff::performance::ResourceCall -> pcm::core::PCMRandomVariable
• pcm::seff::performance::ResourceCall -> pcm::repository::ResourceProvidedRole
• pcm::seff::performance::ResourceCall -> pcm::repository::ResourceSignature
• pcm::entity::ResourceInterfaceProvidingEntity -|> pcm::entity::Entity
• pcm::entity::ResourceInterfaceProvidingEntity <>-> pcm::entity::ResourceProvidedRole
• pcm::entity::ResourceInterfaceProvidingRequiringEntity -|> pcm::entity::ResourceInterfaceProvidingEntity
• pcm::entity::ResourceInterfaceProvidingRequiringEntity -|> pcm::entity::ResourceInterfaceRequiringEntity
• pcm::entity::ResourceInterfaceRequiringEntity -|> pcm::entity::Entity
• pcm::entity::ResourceInterfaceRequiringEntity <>-> pcm::entity::ResourceRequiredRole
• pcm::entity::InterfaceRequiredEntity -|> pcm::entity::ResourceInterfaceRequiringEntity
• pcm::repository::ResourceProvidedRole -> pcm::repository::ResourceInterface
• pcm::resourcetype::ResourceRepository <>-> pcm::resourcetype::ResourceInterface
• pcm::resourcetype::ResourceType -|> pcm::resourcetype::ResourceInterfaceProvidingEntity

Changed:

• Changed cardinality:
  • pcm::repository::ResourceSignature <>-[0..1]--[0..1]-> pcm::repository::Parameter
• Changed end point name:
  • pcm::repository::Parameter --> (dataType__Parameter) pcm::repository::DataType
  • pcm::repository::RepositoryContainments::Repository <>-> (dataTypes__Repository) pcm::repository::RepositoryContainments::DataType
  • pcm::repository::ResourceRequiredRole -> pcm::repository::ResourceInterface
  • pcm::repository::RepositoryContainments::Repository <>-> pcm::repository::RepositoryContainments::DataType
• Changed '_' to '__':
  • pcm::core::composition::ComposedStructure -> pcm::core::composition::AssemblyContext
  • pcm::core::composition::ComposedStructure -> pcm::core::composition::AssemblyConnector
  • pcm::core::composition::AssemblyContext -> pcm::repository::RepositoryComponent
  • pcm::core::composition::AssemblyContext -> pcm::parameter::VariableUsage
  • pcm::repository::RepositoryContainments::Repository <>-> pcm::repository::RepositoryContainments::RepositoryComponent
  • pcm::repository::RepositoryContainments::Repository <>-> pcm::repository::RepositoryContainments::Interface
  • pcm::repository::RepositoryContainments::Repository <>-> pcm::repository::RepositoryContainments::DataType
• Changed generalization:
  • pcm::repository::ResourceRequiredRole -|> RequiredRole
• Moved
  • pcm::repository::ResourceRequiredRole to pcm::entity::ResourceRequiredRole
  • pcm::repository::ResourceInterface to pcm::resourcetype::ResourceInterface
  • pcm::repository::ResourceSignature to pcm::resourcetype::ResourceSignature

Removed:

• pcm::core::entity::ResourceInterfaceRequiringEntity ; Seems to be left-over from intermediate model of Michael Hauck

24.01.2011 (Franz)

(Revision pcm.emx=10788)

Refactored failure type classes:

• renamed classes and associations:
  • pcm::reliability::ApplicationFailureType --> pcm::reliability::SoftwareInducedFailureType
  • pcm::reliability::EnvironmentFailureType --> pcm::reliability::HardwareInducedFailureType
  • pcm::reliability::HardwareInducedFailureType.processingResourceType_EnvironmentFailureType --> pcm::reliability::HardwareInducedFailureType.processingResourceType__HardwareInducedFailureType
  • pcm::reliability::FailureType.repository_FailureType --> pcm::reliability::FailureType.repository__FailureType
  • pcm::repository::Repository::failureTypes_Repository --> pcm::repository::Repository::failureTypes__Repository
• made class abstract:
  • pcm::reliability::FailureOccurrenceDescription
• introduced new classes:
  • pcm::reliability::InternalFailureOccurrenceDescription
  • pcm::reliability::ExternalFailureOccurrenceDescription
• deleted associations:
  • pcm::reliability::FailureOccurrenceDescription.applicationFailureType_FailureOccurrenceDescription
  • pcm::reliability::FailureOccurrenceDescription.internalAction_FailureOccurenceDescription
  • pcm::reliability::FailureOccurrenceDescription.specifiedReliabilityAnnotation_FailureOccurrenceDescription

17.02.2011 (Anne)

Added constraints to metamodel

• For components that communicate remotely, a linking resource has to be between their resource containers.
• More formally: If two AssemblyContext are connected by an AssemblyConnector, and their AllocationContexts reside on different ResourceContainers, then the ResourceContainers must be connected by a linking resource.
• New constraint: CommunicatingServersHaveToBeConnectedByLinkingResource

Reason: I changed network simulation configuration: Latency is always simulated, simulation of throughput and middleware completions can be configured.

06.03.2011 PCM Release 3.2 (Klaus)

• Released PCM 3.2
• SVN tag: PCM_REL_3.2
• URL of the SVN tag: https://svnserver.informatik.kit.edu/i43/svn/code/tags/PCM_REL_3.2

07.03.2011 (Franz)

(Revision pcm.emx=11184)

Added timout modelling for AcquireActions:

• pcm::seff::AcquireAction.timeout
• pcm::seff:.AcquireAction.timeoutValue

Fixed incorrect OCL constraint:

• pcm:seff:ServiceEffectSpecification::ReferencedSignatureMustBelongToInterfaceReferencedByProvidedRole

10.03.2011 (Henning/Micha)

Infrastrukturedition / Resources

(Revision pcm.emx=11227)

Added

• pcm::core::ResourceInterfaceProvidingEntity
• pcm::core::ResourceInterfaceRequiringEntity
• pcm::core::ResourceInterfaceProvidingRequiringEntity
• pcm::core::ResourceProvidedRole
• pcm::core::ResourceRequiredRole
• pcm::seff::performance::ResourceCall
• pcm::resourcetype::ResourceInterface
• pcm::resourcetype::ResourceSignature

11.03.2011 (Franz)

(Revision pcm.emx=11240)

Reliability-related refactorings:

• deleted class pcm::reliability::StopFailureType
• classes SoftwareInducedFailureType, HardwareInducedFailureType, NetworkInducedFailureType now directly inherit from FailureType
• introduced new class pcm::reliability::ResourceTimeoutFailureType that inherits from SoftwareInducedFailureType and has an association to pcm::repository::PassiveResource

13.03.2011 (Franz)

(Revision pcm.emx=11251)

Introduced new OCL constraints:

• pcm::reliability::InternalFailureOccurrenceDescription:NoResourceTimeoutFailureAllowedForInternalFailureOccurrenceDescription
• pcm::reliability::ExternalFailureOccurrenceDescription:NoResourceTimeoutFailureAllowedForExternalFailureOccurrenceDescription

Further changes:

• fixed association between between pcm::reliability::ExternalFailureOccurrenceDescription and pcm::reliability::FailureType (changed association from bidirectional to unidirectional to avoid the PCM repository referencing the PCM system)

14.03.2011 (Micha)

(Revision pcm.emx=11258)

Package renamings to avoid duplicate package names:

• renamed seff::performance to seff::seff_performance
• renamed seff::reliability to seff::seff_reliability
• renamed qos::performance to qosannotations::qos_performance
• renamed qos::reliability to qosannotations::qos_reliability

• ResourceRequiredRole and ResourceProvidedRole now inherit from Role
• ResourceInterface and ResourceSignature now inherit from Entity

(Revision pcm.emx=11261)

Added OCL constraint to check that a ResourceCall references a ResourceSignature that belongs to the referenced ResourceRequiredRole:

• Added constraint ResourceSignatureBelongsToResourceRequiredRole to seff::seff_performance::ResourceCall

(Revision pcm.emx=11265)

Adjusted cardinality of reference ResourceCall.numberOfCalls__ResourceCall

24.03.2011 (Henning)

• removed InfrastructureCall->ProvidedInfastructureRole
• added InfrastructureCall->RequiredInfrastructureRole
• added constraint to check that an infrastructure call references a signature which is part of the (also) referenced required role

(Revision pcm.emx=11396)

31.03.2011 (Henning)

Refactoring of connectors of composite structure

• Added Diagram pcm::core::composition::Connectors
• Added ProvidedDelegationConnector-|>Connector
• Added RequiredDelegationConnector-|>Connector
• Added ComposedStructure<>->Connector
• Removed ComposedStructure<>->ProvidedDelegationConnector
• Removed ComposedStructure<>->RequiredDelegationConnector
• Removed ComposedStructure<>->AssemblyEventConnector
• Removed ComposedStructure<>->AssemblyInfrastructureConnector
• Removed ComposedStructure<>->AssemblyConnector
• Moved DelegationConnection from pcm::repository:: to pcm::core::composition
• Moved Connector from pcm::core::connectors tp pcm::core::composition
• Removed ProvidedDelegationConnector -|> Connector
• Removed RequiredDelegationConnector -|> Connector
• Removed ComposedStructure <>-> ProvidedInfrastructureDelegationConnector
• Removed ComposedStructure <>-> RequiredInfrastructureDelegationConnector
• Added ProvidedInfrastructureDelegationConnector -|> DelegationConnector
• Added RequiredInfrastructureDelegationConnector -|> DelegationConnector
• Removed ComposedStructure <>-> SourceDelegationConnector
• Removed ComposedStructure <>-> SinkDelegationConnector
• Removed ComposedStructure <>-> RequiredResourceDelegationConnector
• Added RequiredResourceDelegationConnector -|> DelegationConnector
• Removed pcm::core::connectors
• Updated constraints
• Added nsPrefix for each subpackage

(Revision pcm.emx=11425)

10.05.2011 (Chris)

Added filter conditions to event connectors

• added AssemblyEventConnector<>->PCMRandomVariable

(Revision pcm.emx=11792)

25.07.2011 (Chris)

Added support for event channels

• pcm.core.composition (Diagram AssemblyEventConnector)
  • Added EventChannelSinkConnector (incl Inheritence Connector)
  • Added EventChannelSourceConnector (incl Inheritence Connector)
  • Added EventChannelSinkConnector --> SinkRole
  • Added EventChannelSourceConnector --> SourceRole
  • Added EventChannelSinkConnector <>-- PCMRandomVariable
  • Added EventChannelSourcConnector --> AssemblyContext
  • Added EventChannelSinkConnector --> AssemblyContext
• pcm.core.composition (Diagram CompositionAndAddemblyContext)
  • Added EventChannel (incl Inheritance from Entity)
  • Added ComposedStructure <>-- EventChannel
  • Added EventChannel --> EventGroup
• pcm.allocation (Diagram Allocation)
  • Changed Cardinality of AllocationContext-->AssemblyContext from 1 to 1..0
  • Added AllocationContext --> EventChannel
  • Added Constraint OneAssemblyContextOrOneEventChannelShouldBeReferred to AllocationContext

revision pcm.emx 12276

04.08.2011 (Chris)

• Added attribute name to LinkingRessource

16.09.2011 (Franz)

• Added attribute pcm::resourceenvironment::ProcessingResourceSpecification.requiredByContainer (for extended reliability modelling and prediction)

23.09.2011 (Micha)

Revision 13376

• Support of nested ResourceContainers: ResourceContainer has * reference nestedResourceContainers__ResourceContainer

20.10.2011 (Chris)

• Added EventChannelSourceConnector-->EventChannel
• Added EventChannelSinkConnector-->EventChannel

23.10.2011 (Franz)

(revision pcm.emx=13510)

Renamings in package "pcm::seff::seff_reliability":

• RecoveryBlockAction --> RecoveryAction
• RecoveryBlockAlternativeBehaviour --> RecoveryActionBehaviour
• RecoveryBlockAction.recoveryBlockAlternativeBehaviours_RecoveryBlockAction --> RecoveryAction.recoveryActionBehaviours__RecoveryAction
• RecoveryBlockAlternativeBehaviour.nextAlternative_RecoveryBlockAlternativeBehaviour --> RecvoryActionBehaviour.nextAlternative__RecoveryActionBehaviour
• RecoveryBlockAlternativeBehaviour.recoveryBlockAction_RecoveryBlockAlternativeBehaviour --> RecvoryActionBehaviour.recoveryAction__RecoveryActionBehaviour

25.10.2011 (Franz)

(revision pcm.emx=13515)

Refactored RecoveryActions in "pcm::seff::seff_reliability":

• added RecoveryBlockAction.primaryBehaviour__RecoveryAction
• changed RecvoryActionBehaviour.nextAlternative__RecoveryActionBehaviour --> RecvoryActionBehaviour.failureHandlingAlternatives__RecoveryActionBehaviour
• added OCL checks to RecoveryBlockAction and RecvoryActionBehaviour

28.11.2011 (Chris)

(revision pcm.emx=13770)

• removed attribute name of LinkingRessource

28.11.2011 / 29.11.2011 (Micha)

(revision pcm.emx=13779)

• allocation::AllocationContext: adapted OCL constraint OneAssemblyContextOrOneEventChannelShouldBeReferred

(revision FeatureConfig.emx=13788)

• featureconfig::ConfigNode: Commented OCL constraint CheckMultiplicityOfFeatureGroup out

15.12.2011 (Chris)

I adapted the simulation, so that it shows an Error message if a no guardedbranch in a Branch transition evaluates to true. This error message substitutes the Runtime Exception which was thrown and stops the execution. This slightly changes the execution semantic, as the execution continuos, comparable to the automatic changes to probabilistc branches. However the error is listet within the Console Log. See bug 973

17.01.2012 (Anne)

I added a OCL constraint to EntryLevelSystemCall to solve Bug BZPCM-371 (formerly 529).

EntryLevelSystemCallSignatureMustMatchItsProvidedRole self.providedRole_EntryLevelSystemCall.providedInterface__OperationProvidedRole.signatures__OperationInterface->includes(self.operationSignature__EntryLevelSystemCall)

I did not generate the PCM code again.

25.01.2012 (Henning)

(revision pcm.emx=14005)

• ResourceDemandingBehaviour --|> Identifier

13.02.2012 (Klaus)

(revision pcm.emx=14143)

• Preparation for PCM 3.3 release: Lifted package version number to "5.0" for all PCM packages

13.02.2012 (Micha)

(revision pcm.emx=14175 (branch))

• Removed enum SchedulingPolicy, added class SchedulingPolicy
  • Scheduling Policies now predefined in Palladio.resourcetype
  • User can add new scheduling policy. ID attribute should be used to dynamically look up scheduler for this id

13.02.2012 (Jörg, Klaus)

(revision pcm.emx/stoex.emx=14179 (branch))

• Fixed issue PALLADIO-23: CommunicationLinkResourceType now inherits from ResourceType instead of ProcessingResourceType. CPU and other can no longer be used as network resource
• StoEx model: changed associativity of TermExpression and ProductExpression
  • TermExpression: type of "left" was Term is now Product; type of "right" was Product is Term now
  • ProductExpression: type of "left" was Product is now Power; type of "right" was Power is Product now

12.04.2012 (Micha, Klaus)

(revision pcm.emx=14959)

• ProcessingResourceSpecification inherits from Identifier now

19.11.2012 (Henning)

(revision pcm.emx=17085)

• Addressed issue Palladio-218: InfrastructureCall, ResourceCall, and ExternalCallAction have OCL constraints which check if referenced roles belong to the component in which the calls/action is contained.

(revision pcm.emx=17104)

• Tested and fixed above OCL constraints

23.11.2012 (Henning)

(revision pcm.emx=17154)

• Addressed issue Palladio-220: InfrastructureCall, ResourceCall, and ParametricResourceDemand have OCL constraints which check if the requested target is unique within the same action.

11.12.2012 (Micha)

(revision pcm.emx=17274)

• Changed attributes types of NamedElement:entityName, Repository:repositoryDescription, ExternalCallAction:retryCount, EntryLevelSystemCall:priority from UML types to Ecore types

15.01.2014 (Micha)

(revision pcm.emx=20424)

• changed multiplicity of ResourceInterface::parameter__ResourceSignature from 1 to *
• code generation: set"Extensible Provider Factory" to true in genmodel properties for all pcm packages

15.01.2014 - 03.07.2015 (Steffen, Sebastian)

(revision pcm.ecore=28150, notice the dropped usage of the emx files from RSA starting from here)

• Made CallAction and SynchronizationPoint become linkable as entities from monitoring specifications
• Updated all PCM packages to new namespace (both Java and eCore namespaces)
• PCM now supports CDO settings

11.08.2015 (Steffen, Sebastian)

(revision pcm.ecore=28746)

• Made call action implement Entity instead of AbstractAction as CallAction is not intended to be used stand-alone

Proposed Changes (please add realised changes above)

1:n mapping of AssemblyContext to AllocationContext (Anne)

(please keep this description as PCM2LQN and PCM2StoEx support this kind of allocation as of PCM 4.0 even if such models are not allowed by the metamodel constraints)

• Motivation: Support a simple replication mechanism with defined (although limited) semantics
• Idea: Allow one AssemblyContext to refer to n AllocationContexts
  • Proposed semantics:
    • Random distribution of calls: A call to a component that has multiple AllocationContexts (i.e. component instances at allocation time and runtime) is uniformly randomly assigned to one of the component instances. That mean, one of the servers is loaded with the demand. The choice is only made once when the call is issued, all subsequent resource demands within this component are directed to the same resource container. One exception to this is described below, concerning local and remote calls.
    • Local precedence:
      • Problem: If several components are replicated in this way, each call an allocation instance of component 1 makes is distributed randomly to all allocation instances of component 2. However, this is usually to the desired behaviour. Consider the figure below, where the system (consisting of two components) has been replicated to two servers. With only the above rule, each allocation context of component 1 would call both allocation contexts of component 2 (dashed and dotted lines). We usually want, however, that only the local instance of component 2 is called. Thus, only the dashed calls should be issued.
      • Idea: Local AllocationContexts get the precedence when calls are distributed. That means, when distributing calls, a local allocation context of the called component is always used if one is available. There are two options how to realize this
        • Constraint: One AllocationContext per AssemblyContext and ResourceContainer: Then, at most local AllocationContext can be available and receive the calls. If no local AllocationContexts is available, the call is distributed uniformly randomly to all remote AllocationContexts.
        • Random local distribution: If there are several local AllocationContexts, then the calls are distributed randomly amongst them only.
    • Passive Resources per AllocationContext: This is an open question: Do several AllocationContexts share a passive resource? I guess that usually does not make sense, and suggest to define the PassiveResource scope to be an AllocationContext, i.e. each component instance has its own instance of the passive resource.
• Required Metamodel Change: Change multiplicity of association between AssemblyContext and AllocationContext from 1:1 to 1:n.
• Required Analysis Changes:
  • PCM Solver:
    • ContextWrapper per AllocationContext, done.
    • PCM2LQN: Branch if several replicas are called, done (in Rdseff2Lqn.java)
    • PCM2StoEx: Branch if several replicas are called, done
    • MarkovSolver: Branch if several replicas are called, TODO
  • SimuCom: Two options, TODO
    • Create component object for each AllocationContext instead of each AssemblyContext as it is currently done(?). This might be the more straightforward option and reflects that indeed several runtime component instances are created. Only matches the "private passive resources per AllocationContext" option (see above).
    • Choose Replica to address resource demands when a component is called, store this internally during the call to address the right resources. Better matches the "shared passive resource among component instances" option above.
  • Protocom: Need to adjust the generated ejb.xml files to instantiate AssemblyContexts at the right places. TODO
  • PCM2QPN: ?, TODO

Keywords: PCM, Palladio, Meta-Model, Metamodell, Model, Changelog, History, Change Documentation, Versions, Versioning, Refactorings