Topcased questions: allocations, parts
Rodrigo
I have two questions specific to Topcased. I hope it is not a problem
for this forum that I already posted the questions on the Topcased
forum. I post them again here in the hope to reach some more Topcased-
savvy users that maybe do not frequent the Topcased list.
The link to the original posts:
http://lists.gforge.enseeiht.fr/pipermail/topcased-users/2011-March/016111.html
http://lists.gforge.enseeiht.fr/pipermail/topcased-users/2011-March/016114.html
The first question deals with allocations:
I have started using Topcased to create a SysML model of a hybrid (H/W
– S/W) product. As we all know, having a language like SysML is one
thing, knowing how to use it is a different one. Guiding us in using
SysML for system development we have different processes. Looking at
the most popular MBSE processes we find the following steps:
Requirements analysis –> Functional analysis –> Allocation of
functions to suitable structural components to derive the architecture
of the system
Requirements analysis, functional analysis and representation of the
structure of the system are very well supported in Topcased. I am
though having trouble with the connection between the functional world
and the structural world in the form of allocations.
First, I cannot find any connector stereotyped < > to connect e.g.
blocks to activities. (http://www.mail-archive.com/topcased-
us...@lists.gforge.enseeiht.fr/msg01641.html)
I know that I can create an allocation in the outline, and at this
allocation identifies the client and supplier elements as properties.
This is not the most efficient/fast way to do allocations, but it is a
possibility. My problem with this is when I do an analysis of the
model to try to answer the following two questions: 1. Have I
allocated all functions to structural components? (or have I forgotten
some functionality?) 2. Have all blocks been allocated from some
activity? (or do I have structural elements which either are not
required by the functionality to be provided, or for which I have
forgotten to define the functionality?).
The way I understand the SysML specification (I am referring to v1.2,
section 15.3.2.2) is that once we have an allocation between two named
elements, there is a relationship between this. This means that the
elements *themselves* know about this relationship, and not only the
relationship holds this information. That is the reason why named
elements in such a relationship have the stereotype <<allocated>>,
with the attributes allocatedFrom and allocatedTo.
The current situation in Topcased (if I have not overseen anything) is
that we can create the allocation only in the outline and have thus
the information only in the underlying model but not in the diagrams
(which does not correspond to the “visual” aspect of this language),
and this allocation is not known by the allocated elements (ok, maybe
partly, because the one defined as “client” has the property “Client
Dependency” pointing to the allocation, but navigation is clumsy and
information incomplete) and is thus not shown in the diagrams as a
stereotype “allocated” on the named element and
“allocatedFrom”/”allocatedTo” attributes visible in a compartment.
So, now finally to my questions:
1. Am I overseeing something regarding creating allocations
graphically and showing this allocation not only in the outline or
even not only through an allocation connector but also in the
compartments of the named elements?
2. How important is this functionality in the overall roadmap for
Topcased, especially being it, as I described in the beginning, at the
_core_ of any MBSE process?
-----------------------------------------
The second question deals with SysML parts:
I have a question regarding SysML parts. My scenario looks as follows:
I have a block called "Environmental conditions". It has several
properties that further define the specific environmental conditions
applicable, e.g. "Temperature range". I then create an IBD to define
my context, which includes a property (=part) whith the type:
"Environmenal conditions" and one with the type of my system being
developed. Since these parts are instances, I would like to specify
the values the properties of these elements take in the specific
"implementation", e.g. "Temperature range" = "-40 to +70 degC". And
after defining these values I would of course like to see them in my
IBD in the compartment of my part, in order to have a visual feedback
to the specifics of my design.
Currently, I have neither found the way to define the values nor to
show these properties in the parts used in the IBD.
I would appreciate any suggestion to achieve the goals described
above. It might be that the way I envision is based on a
misunderstanding of the SysML specification, in that case I am of
course also open for discussion.
---------------------------
I would highly appreciate if someone can comment on these issues.
Kind regards,
Rodrigo
FAUDOU Raphael
De : sysml...@googlegroups.com [mailto:sysml...@googlegroups.com] De la part de Rodrigo
Envoyé : mercredi 30 mars 2011 16:22
À : SysML Forum
Objet : [SysML Forum] Topcased questions: allocations, parts
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
Rodrigo
thank you very much for the precise answers! I am very much looking
forward to those first betas to try out the new features.
Regarding the allocation tables: totally agree with you, allocation
tables can be a huge help especially in reviews. (is this a feature
already present or one that is planned?). And what is also very
important is that both elements involved in the relationship "know"
about this relationship, so that we can have automated mechanisms to
check for completeness and consistency.
Rodrigo
On 30 Mrz., 18:55, FAUDOU Raphael <RAPHAEL.FAU...@atosorigin.com>
wrote:
>
> My comments below,
>
> -----Message d'origine-----
> De : sysml...@googlegroups.com [mailto:sysml...@googlegroups.com] De la part de Rodrigo
> Envoyé : mercredi 30 mars 2011 16:22
> À : SysML Forum
> Objet : [SysML Forum] Topcased questions: allocations, parts
>
> Hello everybody,
>
> I have two questions specific to Topcased. I hope it is not a problem
> for this forum that I already posted the questions on the Topcased
> forum. I post them again here in the hope to reach some more Topcased-
> savvy users that maybe do not frequent the Topcased list.
>
> The first question deals with allocations:
>
> I have started using Topcased to create a SysML model of a hybrid (H/W
> SysML for system development we have different processes. Looking at
> the most popular MBSE processes we find the following steps:
>
Rodrigo
thank you very much for your precise answers! (I will be very
interested to hear what you have to say to the question regarding
SysML parts).
I completely agree with you that the allocation tables are a very
powerful tool. In my experience it is usually the tool of choice when
performing reviews. Is Topcased already able to generate such tables?
And what I also consider to be extremely important is that those
elements involved in an allocation relationship (or any other type of
relationship for that matter!) know about this relationship. This
allows to create automatisms to check for completeness and
consistency.
In any case, I am now very much looking forward to beta-testing
Topcased 5.
Thanks for the hard work!
Rodrigo
FAUDOU Raphael
De : sysml...@googlegroups.com [mailto:sysml...@googlegroups.com] De la part de Rodrigo
À : SysML Forum
Objet : [SysML Forum] Re: Topcased questions: allocations, parts
FAUDOU Raphael
Hello Rodrigo,
Concerning the parts, could you please precise how you intend to specify the "implementation" value of “temperatureRange” property?
Do you want to use an instances diagram and put values in the slots matching the properties?
Do you want to use the "defaut value" feature of "temperatureRange" property?
Here is a small model done with TOPCASED in which a default value defined in BDD on the “tempRange” property (through “advanced tab” of Property view). It can be shown in IBD in the corresponding part (just by dragging the property in the part => the default value is shown automatically).
Would it answer to your need?
If not, perhaps you could send me your simple SysML model so that I can check if I can complete it with the values displayed in IBD?
Thanks
raphaël
-----Message d'origine-----
De : sysml...@googlegroups.com [mailto:sysml...@googlegroups.com] De la part de Rodrigo
Envoyé : mercredi 30 mars 2011 16:22
À : SysML Forum
Objet : [SysML Forum] Topcased questions: allocations, parts
Hello everybody,
--
You received this message because you are subscribed to the Google
Groups "SysML Forum" group.
Public website: http://www.SysMLforum.com
To post to this group, send email to sysml...@googlegroups.com
To unsubscribe from this group, send email to
sysmlforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
Remy
Is it normal procedure to use SysML for implementation purpose? That
may bypass proper consideration of design options.
Rémy.
On Mar 30, 5:22 pm, Rodrigo <rodrig...@yahoo.com> wrote:
> Hello everybody,
>
> I have two questions specific to Topcased. I hope it is not a problem
> for this forum that I already posted the questions on the Topcased
> forum. I post them again here in the hope to reach some more Topcased-
> savvy users that maybe do not frequent the Topcased list.
>
Dan George
levels of abstraction. Viewpoints can be used to formally specify the
purpose of the model to avoid endless questioning about whether an
expression is an architectural element, a design detail, an
implementation detail, etc. SysML is just a modeling language. I don't
see anything that limits its use to design or would cause one to
recklessly omit options.
Dan
On May 3, 9:44 pm, Remy <cami...@gmail.com> wrote:
> Hi,
> Is it normal procedure to use SysML for implementation purpose? That
> may bypass proper consideration of design options.
> Rémy.
>
> On Mar 30, 5:22 pm, Rodrigo <rodrig...@yahoo.com> wrote:
>
>
>
>
>
>
>
> > Hello everybody,
>
> > I have two questions specific to Topcased. I hope it is not a problem
> > for this forum that I already posted the questions on the Topcased
> > forum. I post them again here in the hope to reach some more Topcased-
> > savvy users that maybe do not frequent the Topcased list.
>
Remy Fannader
Dan George
different languages for requirements and design? In practice, I think
we are finding that it is better to use one language and clarify the
perspective. One perspective describes requirements and one describes
design but the language is the same language can be used for both.
I think of requirements v. design as being contextually dependent on
hierarchy. The requirements for a system constrain the design. The
design typically describes a set concepts that combine to meet the
requirements and fit the constraints. The descriptions of those
concepts is design information in the system context but also become
requirements to the design of each concept. The process repeats until
design is not necessary because an existing item can be used (the
design having already been done previously). Having to re-express
design in a requirements language at each level would be cumbersome
and likely error prone. If the re-expression could be made easy and
error-free, however, I could see the value. I just don't know to
achieve it.
Dan
On May 4, 8:30 am, Remy Fannader <cami...@gmail.com> wrote:
> Indeed, as with any language, it's possible to write phrases with correct
> syntax but ambiguous semantics. My point was about the risk of confusion
> when design is mixed with requirements.
>
Dan George
representation more and more. I now create many more diagrams, each
with a focused purpose, rather than trying to have one big picture.
The one big picture is just too difficult to work with. The great
thing about having a model is that you can quickly make different
diagrams showing just what you want in each.
Diagrams are very good for confirming relationships but sometimes not
so good for finding missing ones. Many times the best way to look for
missing things is though model queries.
Just sharing.
Dan
Remy Fannader
To take an example (from the SysML sample problem), the same syntax (e.g composite structure) is used to describe containment, physical connections, and references. Regarding language, the motto should be "say what you mean, mean what you say". And SysML doesn't do the job.
Rémy.
Eirich, Peter
Actually -- it *is* at the very least appropriate, and perhaps even necessary, to employ a different language for requirements than for design. For instance, the primary focus of SysML is to develop and describe the internals of a system block, from the ports inward. This is clearly a white box perspective.
In contrast, the primary focus of a good requirements statement is to explain what a system block should be expected to do from a black box perspective – that is, from the system’s ports outward, in terms of what should be observed externally at the different input and output ports if the system is operating as desired by the requirements writer.
Fundamentally, this requirements view is a different and complementary perspective to the one around which SysML has been developed. Both viewpoints are important. Both are valid. Both have a useful purpose. However, they are *different* viewpoints, and it should not be surprising to find that a language optimized for one of these perspectives might not be the best choice for the other.
So, yes, while it is possible as Dan suggests below that the “same language can be used for both”, this must necessarily force a compromise in the design of the language to serve both purposes. I think SysML has been optimized for design, and to try to use it for requirements as well is to try to “force fit” it into a purpose for which it was never intended. I would not expect very satisfactory results from doing so.
The natural place for a requirements language to interface with a design language is at the *ports* of a system. At those intersection points each language can be used for a verification cross-check against the other, thereby enabling each to do a better job.
Regards,
Peter
_________________________
Peter Eirich
Principal Professional Staff
The Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Road
Mail Stop MP6-S168
Laurel, MD 20723-6099
240-228-7264
peter....@jhuapl.edu
_________________________
Eran Peleg
It is all a matter of a viewpoint ….
Do we have a flat development process? If one look on the abstraction levels of SoS (System of Systems), for example, the Design of the SoS may be the Requirements of each composed System and so on until the very end Class level of a Component. We may describe Requirements as SysML's Requirements or as SoS's UCs (UseCases) with internal flows as ADs (Activity Diagrams) and/or SDs (Sequence Diagrams) that the system may implement – the System requirements. So, if we look on a multi-levels system, we should look on multi-levels Requirements.
And, SysML is not one language. There are at least two levels (or viewpoints) of looking at SysML (as every UML based DSL): a. the language itself with constructs for many modeling disciplines, such as Requirements, Static Design, Dynamic Design, Testing (using Testing Profile), etc.; and b. One may build a DSL (Domain Specific Language) on top of SysML to satisfy a specific domain (or domains). Therefore, again, there is no "SysML Language". SysML itself has domains, and if necessary, other domains can be built on top of it using Profiling (or light weight meta-modeling) and still stay with SysML.
The really important aspect is the ability to achieve Traceability and different views of Allocation; consistency modeling rule checking; and transformation. Therefore, if ONE environment and one underlying language, with DSL adjustments for domains and disciplines is used, the above concept can be reached. SysML is a very good language to play the role of the underlying language as the basis for multi-level system specification (requirements – design), and for modification to domain specific languages to create domain specific models with traceability and transformation capabilities.
The attached picture, from the "MBSE Initiative – SE2 Challenge Team" work, depicts this concept from the SE2 point of view. Other views are legitimate, just because SysML interpretation should be adjusted to the specific project nature.
Best regards
Eran
======================
Eran Peleg, CEO
Metaphor Vision Ltd.
Phone: +972545346060
Fax: 151545346060
eMail: epe...@metaphor.co.il
Skype: EranPelegMetaphor
======================
David Oliver
David Oliver
It looks like a flight for abstraction. It's always possible to call for another level but at the end the only one who knows what's all about is the last who spoke.
Rémy
On 6 May 2011 19:00, Eran Peleg <epe...@metaphor.co.il> wrote:
It is all a matter of a viewpoint ….
Do we have a flat development process? If one look on the abstraction levels of SoS (System of Systems), for example, the Design of the SoS may be the Requirements of each composed System and so on until the very end Class level of a Component. We may describe Requirements as SysML's Requirements or as SoS's UCs (UseCases) with internal flows as ADs (Activity Diagrams) and/or SDs (Sequence Diagrams) that the system may implement – the System requirements. So, if we look on a multi-levels system, we should look on multi-levels Requirements.
And, SysML is not one language. There are at least two levels (or viewpoints) of looking at SysML (as every UML based DSL): a. the language itself with constructs for many modeling disciplines, such as Requirements, Static Design, Dynamic Design, Testing (using Testing Profile), etc.; and b. One may build a DSL (Domain Specific Language) on top of SysML to satisfy a specific domain (or domains). Therefore, again, there is no "SysML Language". SysML itself has domains, and if necessary, other domains can be built on top of it using Profiling (or light weight meta-modeling) and still stay with SysML.
The really important aspect is the ability to achieve Traceability and different views of Allocation; consistency modeling rule checking; and transformation. Therefore, if ONE environment and one underlying language, with DSL adjustments for domains and disciplines is used, the above concept can be reached. SysML is a very good language to play the role of the underlying language as the basis for multi-level system specification (requirements – design), and for modification to domain specific languages to create domain specific models with traceability and transformation capabilities.
The attached picture, from the "MBSE Initiative – SE2 Challenge Team" work, depicts this concept from the SE2 point of view. Other views are legitimate, just because SysML interpretation should be adjusted to the specific project nature.
<image001.jpg>
Jack Ring
Eirich, Peter
With the CAVEAT that I consider state transition analysis to be a part of the procedural side of things, Jack has expressed the main point I was trying to make much more clearly and concisely than I was able to do myself.
After studying SysML, I concluded (rightly or wrongly) that its primary orientation is toward the HOW side of things.
Dan George
it would be great to learn about the logic that lead to your
conclusion. This forum has a knowledgeable membership who could
possibly address shortcomings in the language or help improve
understanding as appropriate. I am also curious about the impact of
your conclusion. Even if a language has a primary orientation toward a
the "how," as you say, is it not possible to express the "what?" Since
what and how are such contextual terms it might be easier to discuss
whether SysML can be productively used to describe a problem. If SysML
can be used to describe a problem I can then use that description as a
basis to evaluate the value of proposed solutions. If the problem
description ends up also describing only one possible solution, well,
I'd say the language isn't useful for problem description purposes.
I'm picking on Peter but anyone with doubts about the utility of SysML
could post what they find challenging and see if the community can
help overcome those challenges. Some will be shortcomings in the
language that can and should be addressed. Others will be
misunderstandings that needlessly limit the benefit one realizes from
modeling.
Respectfully,
Dan
> Fundamentally, this requirements view is a different and complementary perspective to the one around which SysML has been developed. Both viewpoints are important. Both are valid. Both have a useful purpose. However, they are *different* viewpoints, and it should not be surprising to find that a language optimized for one of these perspectives might not be the best choice for the other.
>
> So, yes, while it is possible as Dan suggests below that the "same language can be used for both", this must necessarily force a compromise in the design of the language to serve both purposes. I think SysML has been optimized for design, and to try to use it for requirements as well is to try to "force fit" it into a purpose for which it was never intended. I would not expect very satisfactory results from doing so.
>
> The natural place for a requirements language to interface with a design language is at the *ports* of a system. At those intersection points each language can be used for a verification cross-check against the other, thereby enabling each to do a better job.
>
> Regards,
> Peter
>
> _________________________
> Peter Eirich
> Principal Professional Staff
> The Johns Hopkins University Applied Physics Laboratory
> 11100 Johns Hopkins Road
> Mail Stop MP6-S168
> Laurel, MD 20723-6099
> 240-228-7264
> _________________________
> From: sysml...@googlegroups.com<mailto:sysml...@googlegroups.com> [mailto:sysml...@googlegroups.com] On Behalf Of Remy Fannader
> Sent: Friday, May 06, 2011 1:04 AM
> To: sysml...@googlegroups.com<mailto:sysml...@googlegroups.com>
> Subject: Re: [SysML Forum] Re: Topcased questions: allocations, parts
>
> My point is that SysML requirements cannot be used independently as designers must be familiar non only with the domain but also with the company cultural context. As you say they need to "clarify the perspective".
> To take an example (from the SysML sample problem), the same syntax (e.g composite structure) is used to describe containment, physical connections, and references. Regarding language, the motto should be "say what you mean, mean what you say". And SysML doesn't do the job.
> Rémy.
>
> What should we take form your point? Is it necessary to use two
> different languages for requirements and design? In practice, I think
> we are finding that it is better to use one language and clarify the
> perspective. One perspective describes requirements and one describes
> design but the language is the same language can be used for both.
>
> I think of requirements v. design as being contextually dependent on
> hierarchy. The requirements for a system constrain the design. The
> design typically describes a set concepts that combine to meet the
> requirements and fit the constraints. The descriptions of those
> concepts is design information in the system context but also become
> requirements to the design of each concept. The process repeats until
> design is not necessary because an existing item can be used (the
> design having already been done previously). Having to re-express
> design in a requirements language at each level would be cumbersome
> and likely error prone. If the re-expression could be made easy and
> error-free, however, I could see the value. I just don't know to
> achieve it.
>
> Dan
>
>
> > Indeed, as with any language, it's possible to write phrases with correct
> > syntax but ambiguous semantics. My point was about the risk of confusion
> > when design is mixed with requirements.
>
>
> > > SysML has the essential constructs to describe a system at various
> > > levels of abstraction. Viewpoints can be used to formally specify the
> > > purpose of the model to avoid endless questioning about whether an
> > > expression is an architectural element, a design detail, an
> > > implementation detail, etc. SysML is just a modeling language. I don't
> > > see anything that limits its use to design or would cause one to
> > > recklessly omit options.
>
> > > Dan
>
> > > > Hi,
> > > > Is it normal procedure to use SysML for implementation purpose? That
> > > > may bypass proper consideration of design options.
> > > > Rémy.
>
>
> > > > > Hello everybody,
>
> > > > > I have two questions specific to Topcased. I hope it is not a problem
> > > > > for this forum that I already posted the questions on the Topcased
> > > > > forum. I post them again here in the hope to reach some more Topcased-
> > > > > savvy users that maybe do not frequent the Topcased list.
>
> > > > > The link to the original posts:
> > >http://lists.gforge.enseeiht.fr/pipermail/topcased-users/2011-March/0....
> > > ..
>
> > > > > The first question deals with allocations:
>
> > > > > I have started using Topcased to create a SysML model of a hybrid (H/W
> > > > > SysML for system development we have different processes. Looking at
> > > > > the most popular MBSE processes we find the following steps:
>
> > > > > of the system
>
> > > > > Requirements analysis, functional analysis and representation of the
> > > > > structure of the system are very well supported in Topcased. I am
> > > > > though having trouble with the connection between the functional world
> > > > > and the structural world in the form of allocations.
>
> > > > > First, I cannot find any connector stereotyped < > to connect e.g.
> > > > > blocks to activities. (http://www.mail-archive.com/topcased-
> > > To post to this group, send email to sysml...@googlegroups.com<mailto:sysml...@googlegroups.com>
> > >http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "SysML Forum" group.
> To post to this group, send email to sysml...@googlegroups.com<mailto:sysml...@googlegroups.com>
> For more options, visit this group athttp://groups.google.com/group/sysmlforum?hl=en_US?hl=en
> --
> You received this message because you are subscribed to the Google
> Groups "SysML Forum" group.
> To post to this group, send email to sysml...@googlegroups.com<mailto:sysml...@googlegroups.com>
> For more options, visit this group athttp://groups.google.com/group/sysmlforum?hl=en_US?hl=en
> --
> You received this message because you are subscribed to the Google
> Groups "SysML Forum" group.
> To post to this group, send email to sysml...@googlegroups.com<mailto:sysml...@googlegroups.com>
> For more options, visit this group athttp://groups.google.com/group/sysmlforum?hl=en_US?hl=en
> --
> You received this message because you are subscribed to the Google
> Groups "SysML Forum" group.
> To post to this group, send email to sysml...@googlegroups.com<mailto:sysml...@googlegroups.com>
> For more options, visit this group athttp://groups.google.com/group/sysmlforum?hl=en_US?hl=en
Rodrigo
what you show in your attachments is exactly what I am looking for. Now imagine that we want to start building a sort of components library. We have an Environment block with a temperature range. Then I model one environment (part) "Sahara" of type "Environment" and one environment (part) "Siberia" of type "Environment". If I have both in my model, I have no way of setting a different value for the temperature range.
Indeed, the instance specifications might be what I am looking for. I cannot find much information on them, though, they seem to be poorly documented. It will be highly appreciated if you can provide an example of their usage in Topcased.
Looking at https://groups.google.com/d/topic/sysmlforum/XbpLScfvbxU/discussion, which I just found, it seems like using redefined properties might as well be an alternative, although here again it is not clear to me how this is to be used. What do you think about that?
Best regards,
Rodrigo