Hi Bernard,
There seems to be a confusion between the different modeling levels. The stereotypes (Level: M2) are applied (“Instantiated”) on the Model (Level: M1). They
can be applied on any UML element (Classes, Instance Specifications, Behaviors, ...). They don’t exist in the Application (M0), unless you have a specific way to generate something from them.
Regarding UML Instance Specifications, they are not real instances of UML Classes, because they are on the same modeling level (M1). They are typically used
to define “default values”, or to provide some examples of object relationships (Note: I’m aware that’s a little bit controversial, as many people use them as actual M0 instances).
In your case, it seems that an Abstract Class would be more appropriate than a Stereotype.
In Seb’s example (And in SysML), the requirements do not exist at the application level: they exist at the M1 level (Specification level). Classes (and other UML concepts) should be traced to Requirements (Which are also implemented as extensions of UML Classes,
but have semantically not much to do with UML Classes: Class is a very generic and extensible concept, since it can have a structure and a behavior; this often makes it the default choice when creating a new Stereotype)
Typical usage of SysML Requirements:
Modeling requirements with SysML:
Modeling the application, with traceability links to the Requirements:
 
You can see that Requirements are included into the same model (To allow traceability). Also, note that the SysML Profile is not designed to build a Requirements
Application: it is designed to allow modeling Requirements in UML Models (Which is slightly different: the target modeling level is M1, not M0). This is probably the reason why you cannot/shouldn’t reuse/extend SysML Stereotypes for modeling a requirements
management application.
Of course, everything I described depends on a specific methodology. UML itself is generic enough, so that you could provide your own methodology on top of
it: nothing prevents you from instantiating your Stereotypes at the M0 level (But then, in my opinion, it doesn’t really make sense to use stereotypes: abstract or concrete classes are more appropriate).
So, to summarize, you should either:
-
Create a profile, which extends SysML, and use it at the M1 level (i.e. you don’t build a “Domain-specific application”, you build a “Domain-specific
modeling language/tool”)
-
Create a model, unrelated to SysML, and generate your application (The application is now independent from UML, but the application itself is not
model-based: it has been designed with models)
Regards,
Camille
De : polarsys-iwg-bounces@xxxxxxxxxxx [mailto:polarsys-iwg-bounces@xxxxxxxxxxx]
De la part de bernard.granier
Envoyé : samedi 2 août 2014 14:54
À : Polarsys IWG
Objet : Re: [polarsys-iwg] papyrus, stereotypes and properties
You will be far away from internet ? how could that be ? :)
Ok. My first concern is to show that a profile helps to model applications dedicated to a specific domain.
I choose SysML and the Requirement stereotype for that.
My thought was to model an application which manages requirements, and to use the Requirement stereotype to show that using a prototype I do not need to redo waht
has been done with the stereotype.l
Then I modelized a Requirements manager (TechRequirementManager) which manages requirements (TechRequirement) and I thought to apply the SysML Requirement stereotype
in order to not define id and text properties in the class TechRequirement since they are already defined in the SysML::Requirement stereotype.
But after our discussion, it seems that SysML can not be used to model an application but straightforward a system, that would mean that a profile is done at the
M2 level to help to create object/instance diagram at M1 level and not class diagram at M1 level.
I am still not sure if in your sample, MyTeachReq1 is a class or an instance. It is modeled like a class but used like an instance since the values of id and text
are fixed ...
Bernard Granier
8 rue Michel de l'Hospital
95310 Saint Ouen l'Aumone
01 30 37 27 84
----- Original Message -----
Sent: Friday, August 01, 2014 11:42 AM
Subject: Re: [polarsys-iwg] papyrus, stereotypes and properties
See below.
Best… Sébastien.
Ps : BTW, I will on vacation from today (in few hours ;-) until end of August, so if I did not respond anymore it is not because I do not want, it is just because
I am far away from any devices enabling access to internet… ;-)
------------------------------------------------------------------------------------------------------------------------------------------
Sébastien Gérard
Head of the LISE labs and leader of the Eclipse Papyrus project (www.eclipse.org/papyrus).
+33 (0)1 69 08 58 24 / +33(0)6 88 20 00 47
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
DILS/Laboratoire
d’Ingénierie dirigée par les modèles pour les Systèmes Embarqués (LISE),
Point Courrier n°174
91 191 Gif sur Yvette CEDEX
In fact, I agree with your message but I do not understand the conclusion.
My purpose is to show how a profil can be used efficiently, to show how a profile defines a DSML and then helps to design applications dedicated to requirements management
(in my example). Profiles are done for that no ?
[Seb> ] yes for sure. May be I need you to explain me again in plain text what you want to model? Is it possible?
If SysML is at M2, it is done to create models at M1 by appying stereotypes to classes defines
in M1 models no ? If not, that could explain my misunderstanding.
In your sample, MyTeachReq1 is a class at M1 or an instance ?
Sincerly and again a great thanks,
Bernard Granier
8 rue Michel de l'Hospital
95310 Saint Ouen l'Aumone
01 30 37 27 84
----- Original Message -----
Sent: Thursday, July 31, 2014 12:32 PM
Subject: Re: [polarsys-iwg] papyrus, stereotypes and properties
Stereotype are defined at the M2 level. Defining a sterotype enable you then to create instance of that stereotype at M1 level, in what we usually called user
model. M2 level being usually dedicated to metamodellers, i.e. language designers, i.e. people in charge of defining the language concept used for modeling at M1 level). SysML enables you then to create instance of Requirements with id and text. The standard
says that the id has to be unique and then it is up to the tool to check this rule or to foster this rule when creating new requirement.
In your case, it seems to me that you wanted to create a new kind of requirement introducing this concept of TeachRequirement. As I told you in previous email,
if you want to use SysML, you have to create an extension of the SysML stereotype by generalizing this latter. Now, I understand you want to have a concept of TeachRequirement manager. So it seems to me that you want to create an application in charge of managing
teaching requirement. In that case, I understand it is not a specific modeling language for modeling teaching requirements that you want design but an application. If it is right, I guess you get the right conclusion that you don jot have to use SysML req
stereotype for that purpose. What you intend to do is at M1 level while SysML::Requirement is defined at M2 level.
Best… Sébastien.
------------------------------------------------------------------------------------------------------------------------------------------
Sébastien Gérard
Head of the LISE labs and leader of the Eclipse Papyrus project (www.eclipse.org/papyrus).
+33 (0)1 69 08 58 24 / +33(0)6 88 20 00 47
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
DILS/Laboratoire
d’Ingénierie dirigée par les modèles pour les Systèmes Embarqués (LISE),
Point Courrier n°174
91 191 Gif sur Yvette CEDEX
A great thanks for the images, I can not open your files in polarsys 0.7 but what I understood is that MyTeachReq1 and MyTeachReq2 are classes (right ? otherwise
these names should be underlined). If this is not classes, I am lost because to model an application, I never use object (instance) diagram.
And if I understood correctly your proposition, all instances of MyTeachReq1 will have the same id and the same text, and the same for MyTeachReq2 ...
So if I want to model an application which manages an unknown number of requirements (each one wiht a different id and and a different text) SysML stereotypes are
not usefull ...
In fact, I wanted to model something like the class diagram shown by NewDiagram.jpeg (joined file) but without defining again id and text since I thought to apply
SysML::Requirement to TeachRequirement. Of course, an instance of TeachRequirementManager manages an unknown number of TeachRequirement, each TeachRequirement instance having an unique id and a specific text.
If my thought is not possible, I do not understand how id and text properties of SysML::Requirement can be used ... What could the interest to define a unique id
shared by all requirements and maybe not used by an application since these properties are not included in generated java files. (if I understood correctly your first answer).
PS : I read "carefully" PapyrusUserGuideSeries_AboutUMLProfile_v1.0.0_d20120606.pdf , so I do not think that my problem is about Papyrus UI usage ...
Bernard Granier
8 rue Michel de l'Hospital
95310 Saint Ouen l'Aumone
01 30 37 27 84
----- Original Message -----
Sent: Wednesday, July 30, 2014 5:11 PM
Subject: Re: [polarsys-iwg] papyrus, stereotypes and properties
See below.
In addition attahced to this email is an example of profile specializing SysML::Req and a model applying this new profile.
Séb.
------------------------------------------------------------------------------------------------------------------------------------------
Sébastien Gérard
Head of the LISE labs and leader of the Eclipse Papyrus project (www.eclipse.org/papyrus).
+33 (0)1 69 08 58 24 / +33(0)6 88 20 00 47
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
DILS/Laboratoire
d’Ingénierie dirigée par les modèles pour les Systèmes Embarqués (LISE),
Point Courrier n°174
91 191 Gif sur Yvette CEDEX
Again thanks for the discussion.
I am a little confused by :
"
But how two different instances of TeachRequirement could have different values for id, if id is not like a class properties ?
[Seb> ] it is not possible"
"If it is not possible
how the constraint of id uniqueness can be fullfilled ?
[Seb> ] It is up to the tool to implement something to check that id are different. In Papyrus, we have not yet implement such check o,n the id of a requirement.
I take it as an action on our side.
My goal is to use the Requirement stereotype defined in SysML to model an application managing requirements and to use the properties id and text. It is "obvious"
that a requirement is defined by a string and is identified by an unique id. The fact that id and text are defined in SysML::Requirement should avoid the need to define again these properties in my application model, no ?
[Seb> ] If you define a new stereotype as a generalization of the SysML ::Requirement stereotype you will inherit the id and description properties of
this latter.
"create a new stereotype <<TeachRequirement>> that has to generalize the SysML::Requirement
stereotype"
I am not sure to understand "that has to generalize" With what you suggested : <<TeachRequirement>> is a stereotype which inherits (hérite) from SysML::Requirement
or <<TeachRequirement>> extends SysML::Requirement (but extension is between a meta class and a stereotype). It would be strange to create a stereotype <<TeachRequirement>> and to model that SysML::Requirement inherits (hérite) from <<TeachRequirement>> ...
Anyway, I do not understand that a new stereotype creation could solve my question, <<TeachRequirement>> will be a stereotype applied to a class, like SysML::Requirement,
so how could that solved the question of id usage and uniqueness ?
[Seb> ] uniqueness has to be checked by the tool.
Bernard Granier
8 rue Michel de l'Hospital
95310 Saint Ouen l'Aumone
01 30 37 27 84
----- Original Message -----
Sent: Wednesday, July 30, 2014 11:58 AM
Subject: Re: [polarsys-iwg] papyrus, stereotypes and properties
See below.
Best… Sébastien.
------------------------------------------------------------------------------------------------------------------------------------------
Sébastien Gérard
Head of the LISE labs and leader of the Eclipse Papyrus project (www.eclipse.org/papyrus).
+33 (0)1 69 08 58 24 / +33(0)6 88 20 00 47
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
DILS/Laboratoire
d’Ingénierie dirigée par les modèles pour les Systèmes Embarqués (LISE),
Point Courrier n°174
91 191 Gif sur Yvette CEDEX
First, thanks for your answer, I understood it from a theorical point of view.
But if look to SysML (V 1.3 june 2012) and if I want to model to model requirements in my application named ProfileTeach :
- I will create a classe diagram named teach
- I will model a class TeachRequirementManager
- I will model a class named TeachRequirement
- I will add a composite link 0..* between TeachRequirementManager and TeachRequirement
- I will apply stereotype SysML::Requirements::Requirement to TeachRequirement and what should I do with the stereotype properties text and id ?
What I understood from your answer is that all TeachRequirement instances will have same values for text and id, if tihs is the case the interest of these properties
is meaningless because two different instances of TeachRequirement should not have the same id. The uniqueness of id is defined in SysML (16.3.2.3 p 148)
[Seb> ] you are right.
But how two different instances of TeachRequirement could have different values for id, if id is not like a class properties ?
[Seb> ] it is not possible. If I understand what you want to do, it is to create a new subcategory of Requirement called TeachRequirement. In that case,
what you should do is to extend the SysML profile for RE (Requirement Engineering) and create a new stereotype <<TeachRequirement>> that has to generalize the SysML::Requirement stereotype. Then you can create several instance of TeachReqProfile::TeachRequirement
by creating new classes stereotyped with it.
Of course, I am hardly/strongly (?) interested by one answer ...
[Seb> ] Hope it helps.
Bernard Granier
8 rue Michel de l'Hospital
95310 Saint Ouen l'Aumone
01 30 37 27 84
----- Original Message -----
Sent: Tuesday, July 29, 2014 5:49 PM
Subject: Re: [polarsys-iwg] papyrus, stereotypes and properties
Hi,
See below some answers.
Best… Sébastien.
------------------------------------------------------------------------------------------------------------------------------------------
Sébastien Gérard
Head of the LISE labs and leader of the Eclipse Papyrus project (www.eclipse.org/papyrus).
+33 (0)1 69 08 58 24 / +33(0)6 88 20 00 47
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
DILS/Laboratoire
d’Ingénierie dirigée par les modèles pour les Systèmes Embarqués (LISE),
Point Courrier n°174
91 191 Gif sur Yvette CEDEX
I defined a stereotype with two properties : name of type String, and size of type Real.
I create a class diagram with one class MyClass, applied my stereotype to this class, I found how to display stereotype attributes but without the attributes types.
Is there a way to display types of stereotype attributes in class diagram ? (not a profil diagram but a class diagram)
[Seb> ] Stereotpypes and their propertiers are indeed metainformation. When you applied a stereotype on a class as for example, it is like creating an
instance of kind of class, the stereotype, and to assign value to its slots. So, it is not possible within a class diagram to display the type of the properties of a stereotype: you can also display the property which are indeed a kind of slot (in the sense
of slot of an instance specification in UML) and the value of the slot.
A more general question about stereotype properties, are they like class properties ? I mean, in my case, if I generate a java file MyClass.java, should name and
size be generated as properties of MyClass ?
[Seb> ] no, they are not. Properties of stereotype are more similar to meta-properties of the Class, e.g. the isAbstract meta-properties of the meta class
Class.
Bernard Granier
8 rue Michel de l'Hospital
95310 Saint Ouen l'Aumone
01 30 37 27 84
|
![]()
|
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection
Antivirus avast! est active.
|
_______________________________________________
polarsys-iwg mailing list
polarsys-iwg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/polarsys-iwg
|
![]()
|
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection
Antivirus avast! est active.
|
_______________________________________________
polarsys-iwg mailing list
polarsys-iwg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/polarsys-iwg
|
![]()
|
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection
Antivirus avast! est active.
|
_______________________________________________
polarsys-iwg mailing list
polarsys-iwg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/polarsys-iwg
|
![]()
|
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection
Antivirus avast! est active.
|
_______________________________________________
polarsys-iwg mailing list
polarsys-iwg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/polarsys-iwg
|
![]()
|
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection
Antivirus avast! est active.
|
_______________________________________________
polarsys-iwg mailing list
polarsys-iwg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/polarsys-iwg
|
![]()
|
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection
Antivirus avast! est active.
|
|
