[palladio-dev] [sdq-dev] Invariants for subtypes at wrong location in PCM

Michael Langhammer langhamm at ipd.uni-karlsruhe.de
Wed Sep 3 09:13:07 CEST 2014


Hi Max,

> some hard-working students discovered that at least the invariant
> AtLeastOneInterfaceHasToBeProvidedOrRequiredByAUsefullCompleteComponentType
> of the PCM works not as expected for BasicComponents because it is
> located at the subtype CompleteComponentType and not at the supertype
> RepositoryComponent.
I am not sure whether AtLeastOneInterfaceHasToBeProvidedOrRequiredByAUsefullCompleteComponentType is correct for RepositoryComponent.
Thus a component with only one required interface would be a valid component. 
I thought a component should provide at least one interface to be a valid and useful component. (?)
I guess we would need a more restricting invariant like AtLeastOneInterfaceHastToBeProvidedByAUsefulRepositoryComponent for RepositoryComponent.

> Is anybody willing to do this, e.g. for the next release? I am happy to
> provide the minimal example but I would not be comfortable with moving
> invariants in the PCM without knowing the side-effects (i.e. code
> locations where it is assumed that these invariants are not evaluated).
We may could discuss this in the next Palladio concall.

Kind regards,

Michael

On 02 Sep 2014, at 07:33, Max Kramer <max.kramer at kit.edu> wrote:

> Hello everybody,
> 
> some hard-working students discovered that at least the invariant
> AtLeastOneInterfaceHasToBeProvidedOrRequiredByAUsefullCompleteComponentType
> of the PCM works not as expected for BasicComponents because it is
> located at the subtype CompleteComponentType and not at the supertype
> RepositoryComponent.
> 
> I was able to reproduce the error in Eclipse Luna with a minimal
> example: For every instance of a metaclass only the invariants of this
> metaclass and all supertypes are evaluated. Invariants at siblings are
> ignored. This means the location of an invariant is sometimes crucial.
> 
> For the PCM this means that the invariant
> AtLeastOneInterfaceHasToBeProvidedOrRequiredByAUsefullCompleteComponentType
> and possibly further invariants of the PCM have to be moved up to the
> common ancestor for all metaclasses for which they should be evaluated.
> 
> Is anybody willing to do this, e.g. for the next release? I am happy to
> provide the minimal example but I would not be comfortable with moving
> invariants in the PCM without knowing the side-effects (i.e. code
> locations where it is assumed that these invariants are not evaluated).
> 
> Cheers,
> 
> Max
> 
> -- 
> 
> 
> -----------------------------------------------------------------
> Karlsruhe Institute of Technology (KIT)
> IPD Reussner -- Software Design and Quality
> 
> Dipl.-Inform. Max Kramer
> Researcher
> 
> Am Fasanengarten 5, Building 50.34, Room 241
> D-76131 Karlsruhe, Germany
> 
> Phone: +49 721 608 45994
> Fax: +49 721 608 45990
> http://sdq.ipd.kit.edu/people/max_e_kramer
> 
> KIT -- University of the State of Baden-Wuerttemberg and National Research Center of the Helmholtz Association
> 
> 
> _______________________________________________
> Palladio-Bench developer mailing list. News and discussions on the Palladio software architecture simulator and related tooling projects.
> palladio-dev at ira.uni-karlsruhe.de
> https://lists.ira.uni-karlsruhe.de/mailman/listinfo/palladio-dev
> _______________________________________________
> sdq-dev mailing list
> Liste der Studenten und Mitarbeiter von SDQ fuer SDQ-bezogene Ankuendigungen.
> sdq-dev at ira.uni-karlsruhe.de
> https://lists.ira.uni-karlsruhe.de/mailman/listinfo/sdq-dev




More information about the palladio-dev mailing list