|
Hi,
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
dIngé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é : vendredi 1 août
2014 11:38
À : Polarsys IWG
Objet : Re:
[polarsys-iwg] papyrus, stereotypes and
properties
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
dIngé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
dIngé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
dIngé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
dIngé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.
|
|
