Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [polarsys-iwg] papyrus, stereotypes and properties

Hi,
 
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 ?
 
 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

 

De : polarsys-iwg-bounces@xxxxxxxxxxx [mailto:polarsys-iwg-bounces@xxxxxxxxxxx] De la part de bernard.granier
Envoyé : mercredi 30 juillet 2014 23:04
À : Polarsys IWG
Objet : Re: [polarsys-iwg] papyrus, stereotypes and properties

 

Hi,

 

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

 

De : polarsys-iwg-bounces@xxxxxxxxxxx [mailto:polarsys-iwg-bounces@xxxxxxxxxxx] De la part de bernard.granier
Envoyé : mercredi 30 juillet 2014 16:40
À : Polarsys IWG
Objet : Re: [polarsys-iwg] papyrus, stereotypes and properties

 

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

De : polarsys-iwg-bounces@xxxxxxxxxxx [mailto:polarsys-iwg-bounces@xxxxxxxxxxx] De la part de bernard.granier
Envoyé : mercredi 30 juillet 2014 11:50
À : Polarsys IWG
Objet : Re: [polarsys-iwg] papyrus, stereotypes and properties

Hi,

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

De : polarsys-iwg-bounces@xxxxxxxxxxx [mailto:polarsys-iwg-bounces@xxxxxxxxxxx] De la part de bernard.granier
Envoyé : lundi 28 juillet 2014 17:35
À : Polarsys IWG
Objet : [polarsys-iwg] papyrus, stereotypes and properties

Hi,

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.



Back to the top