AW: [Spam.X angeforderte Email: ][SysML Forum] SysML and building modelling

[Tim Weilkiens]

Hi,

 

Although a use case has a starting point and end points, it could also have a continuous behavior between these points. I would mark those use cases with a stereotype “continuous use case”

(http://www.sysmod.de/sysmod.profile.en/guidances/supportingmaterials/Stereotype_usecases_3A98DCB5.html).

 

A dam or a building in general has functions that provide value to actors or stakeholders of the system. These are the use cases.

 

Tim

 

 

Von: sysml...@googlegroups.com [mailto:sysml...@googlegroups.com] Im Auftrag von Baudouin MARTIN
Gesendet: Mittwoch, 11. April 2012 09:14
An: sysml...@googlegroups.com
Betreff: [Spam.X angeforderte Email: ][SysML Forum] SysML and building modelling

 

Hi All,

 

I have to model a river dam in SysML but for me it's not as obvious as a mecatronic system. My question is about use case. What king of use case can we find for such a system ? A use case has a starting point and an end point. So what about with buildings in general (like a passive house for example) ? If we consider that there is no other subsystems than the building, can we find use case ? If so, then the starting point would be the construction of the building, and the end point the destruction ? I hope it's clear...

 

Thanks for your reponse,

 

BM

 

 

--
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 Fannader]

I'm not sure that's necessary and it could even be confusing. The distinction should be between:
- Use cases monitoring (discrete) events.
- Use cases managing continuous input or output flows.
- Use cases associated with batch processing.
http://caminao.wordpress.com/how-to-implement-symbolic-representations/patterns/functional-patterns/use-case-patterns/
Rémy.

[Dan George]

Use cases highlight the interactions between user and system. Use
cases involving monitoring will highlight the users need to be able to
observe specific properties of the system and the system's
responsibility to make that possible. Cases for managing continuous I/
O show the need for the operator to adjust the system and the system's
responsibility to make that possible. The use cases will clarify the
conversions needed between user and system such that the system is
realizable and satisfies the goals of the user.

Having said all of that, is seems best to organize use cases by goal
rather than type of internal activity or interaction. Maintenance,
operation, installation, decommissioning, ...

Dan

On Apr 13, 7:24 am, Remy Fannader <cami...@gmail.com> wrote:
> I'm not sure that's necessary and it could even be confusing. The
> distinction should be between:
> - Use cases monitoring (discrete) events.
> - Use cases managing continuous input or output flows.

> - Use cases associated with batch processing.http://caminao.wordpress.com/how-to-implement-symbolic-representation...
> Rémy.
>
> On 12 April 2012 11:21, Tim Weilkiens <Tim.Weilki...@oose.de> wrote:
>
>
>
>
>
>
>
> >  Hi,****
>
> > ** **

>
> > Although a use case has a starting point and end points, it could also
> > have a continuous behavior between these points. I would mark those use

> > cases with a stereotype “continuous use case”****
>
> > (
> >http://www.sysmod.de/sysmod.profile.en/guidances/supportingmaterials/...
> > ).****
>
> > ** **

>
> > A dam or a building in general has functions that provide value to actors

> > or stakeholders of the system. These are the use cases.****
>
> > ** **
>
> > Tim****
>
> > ** **
>
> > ** **
>
> > *Von:* sysml...@googlegroups.com [mailto:sysml...@googlegroups.com] *Im
> > Auftrag von *Baudouin MARTIN
> > *Gesendet:* Mittwoch, 11. April 2012 09:14
> > *An:* sysml...@googlegroups.com
> > *Betreff:* [Spam.X angeforderte Email: ][SysML Forum] SysML and building
> > modelling****
>
> > ** **
>
> > Hi All,****
>
> > ** **

>
> > I have to model a river dam in SysML but for me it's not as obvious as a
> > mecatronic system. My question is about use case. What king of use case can
> > we find for such a system ? A use case has a starting point and an end
> > point. So what about with buildings in general (like a passive house for
> > example) ? If we consider that there is no other subsystems than the
> > building, can we find use case ? If so, then the starting point would be
> > the construction of the building, and the end point the destruction ? I

> > hope it's clear...****
>
> > ** **
>
> > Thanks for your reponse,****
>
> > ** **
>
> > BM****
>
> > ** **
>
> > ** **

>
> > --
> > 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****

[Baudouin MARTIN]

Hi,

thanks to all for your response. I'm quite new in SysML but I understand this language more and more and I like it. 

Although a use case has a starting point and end points, it could also have a continuous behavior between these points. I would mark those use cases with a stereotype “continuous use case”

(http://www.sysmod.de/sysmod.profile.en/guidances/supportingmaterials/Stereotype_usecases_3A98DCB5.html).

Ok I understand what you mean and this precision can be usefull. 

 

A dam or a building in general has functions that provide value to actors or stakeholders of the system. These are the use cases.

I'm ok with that and this is the general definition of what is a use case. But in my mind a use case is a service given by the system to an actor. For example, you can prepare a machine who's role is to product mechanical pieces. In that case, there is a start (push on a button) and a stop (the machine producted mechanical pieces). So the service was rendered. We can easily describe this scenario with a Sequence Diagram, a State Machine Diagram or an Activity Diagram. But in the case of a passive house with strictly no other subsystems inside. Its role is to capture and keep heat. The start point will the end of the construction of the house wich is quite different than pushing a button. More precisely, we can also consider that the starting point of this service is when all doors and windows are closed. Discribing this scenario is less obvious because we are not with a classical industrial machine. Can we say that this house has a behavior ? If not, don't we have to say that there is no use case (which is in the behavioral diagrams group). Another question : do all things have a use case ? Silly example :  does a hammer have a use case ? I would say no because the real system is the "human + hammer".

We must keep in mind that SysML can not model effectively all kind of system. So in the case of buildings, maybe should I consider only the structural point of view.

BM

[Baudouin MARTIN]

Hi,

2012/4/13 Remy Fannader <cam...@gmail.com>

I'm not sure that's necessary and it could even be confusing. The distinction should be between:
- Use cases monitoring (discrete) events.
- Use cases managing continuous input or output flows.
- Use cases associated with batch processing.
http://caminao.wordpress.com/how-to-implement-symbolic-representations/patterns/functional-patterns/use-case-patterns/

In my case, the system is quite complex because the river dam contains many other subsystems. What you say here is very interesting and I'm right with that.

BM

[Baudouin MARTIN]

2012/4/14 Dan George <dgeorg...@gmail.com>

Use cases highlight the interactions between user and system. Use
cases involving monitoring will highlight the users need to be able to
observe specific properties of the system and the system's
responsibility to make that possible. Cases for managing continuous I/
O show the need for the operator to adjust the system and the system's
responsibility to make that possible. The use cases will clarify the
conversions needed between user and system such that the system is
realizable and satisfies the goals of the user.

well summarized 

 

Having said all of that, is seems best to organize use cases by goal
rather than type of internal activity or interaction. Maintenance,
operation, installation, decommissioning, ...

yes I'm right with this idea. And I have another question. Maintenance is for me something that needs to be discussed. A use case is a service discribed by an actor and rendered by the system. I think that Maintenance is not automaticially a Use Case. I mean that most systems can be maintained. But all the system do not have fonctionnality for Maintenance. For example, olds cars can be maintained but their model do not have a use case Maintenance. At the opposite, modern cars have an embedded computer and can give informations on the status of the car. In that case, Maintenance is a Use Case because something had to be developped for that. Are we ok with that ?

BM

[Tim Weilkiens]

Every system has a function that is provided to actors. Therefore you always have a use case. A house could have a use case like “House people” and of course several orthogonal nonfunctional requirements like Warming, Rain shield, Wind shield, Size, and so on. “House warming” is a continuous use case. Typically the trigger for continuous use cases is a change of the system state, e.g. the house is habitable. It has no final result, but continuous results. Again the end of a continuous use case is typically triggered by a system change, e.g. house is demolished. A hammer could have the use case “Hammer something”. It seems strange to describe use cases for systems like hammer or houses. Although there may be only a few meaningful use cases they put a focus on the real goal of the system.

 

Tim

 

 

Von: sysml...@googlegroups.com [mailto:sysml...@googlegroups.com] Im Auftrag von Baudouin MARTIN

Gesendet: Samstag, 14. April 2012 19:08
An: sysml...@googlegroups.com

Betreff: [Spam.X angeforderte Email: ]Re: [Spam.X angeforderte Email: ][SysML Forum] SysML and building modelling

 

Hi,

 

thanks to all for your response. I'm quite new in SysML but I understand this language more and more and I like it. 

Although a use case has a starting point and end points, it could also have a continuous behavior between these points. I would mark those use cases with a stereotype “continuous use case”

(http://www.sysmod.de/sysmod.profile.en/guidances/supportingmaterials/Stereotype_usecases_3A98DCB5.html).

 

Ok I understand what you mean and this precision can be usefull. 

 

A dam or a building in general has functions that provide value to actors or stakeholders of the system. These are the use cases.

 

I'm ok with that and this is the general definition of what is a use case. But in my mind a use case is a service given by the system to an actor. For example, you can prepare a machine who's role is to product mechanical pieces. In that case, there is a start (push on a button) and a stop (the machine producted mechanical pieces). So the service was rendered. We can easily describe this scenario with a Sequence Diagram, a State Machine Diagram or an Activity Diagram. But in the case of a passive house with strictly no other subsystems inside. Its role is to capture and keep heat. The start point will the end of the construction of the house wich is quite different than pushing a button. More precisely, we can also consider that the starting point of this service is when all doors and windows are closed. Discribing this scenario is less obvious because we are not with a classical industrial machine. Can we say that this house has a behavior ? If not, don't we have to say that there is no use case (which is in the behavioral diagrams group). Another question : do all things have a use case ? Silly example :  does a hammer have a use case ? I would say no because the real system is the "human + hammer".

We must keep in mind that SysML can not model effectively all kind of system. So in the case of buildings, maybe should I consider only the structural point of view.

 

BM

[Jack Ring]

Pls share an example Use Case regarding Do No Harm.

[Robert Halligan]

Jack, “do no harm” is not a function, and cannot therefore be the subject of a use case.

Robert

[Jack Ring]

Robert, 

Wow, what a claim.

Pls tell us what you think a resilient system does for its user. 

Then tell us how you would request resilient behavior in a use case. 

Then tell us where you got the idea that a use case can request only a function.

Jack 

On Apr 16, 2012, at 8:01 PM, Robert Halligan wrote:

Jack, “do no harm” is not a function, and cannot therefore be the subject of a use case.

Robert

[Alan]

Each use case should have a user goal. It is most clear to name a use
case starting with a verb that describes that goal. Some use case
names suggested here would work.

Alan

[Dan George]

Tim, wouldn't it be better to put the focus on the goals the user has
for using the system? The system, of course, has no goals; it is the
user who has goals and wants to know how the system affects their
ability to achieve them.

Jack, your "Do no harm" goal is certainly a legitimate goal. I would
be interested to see what you have in mind for the scenarios
associated with that use case goal. It seems like that is a goal that
would be considered when evaluating the scenarios of all use cases. Do
any of the proposed interactions pose a risk to the "Do no harm" goal?

Goal: Do no harm
Scenario A - precondition: the system is in "safe mode"
1. user points system at foot
2. user commands system to fire
3. system ignores command
4. user moves on to next potentially harmful scenario

Scenario B
...
Scenario ZZ
...

Perhaps there is a better choice of goals to elaborate and still
describe system interactions in a way that validates safe operation.
The are an infinite number of equally acceptable ways to not do
something.

Dan

Dan

On Apr 15, 10:06 pm, Tim Weilkiens <Tim.Weilki...@oose.de> wrote:
> Every system has a function that is provided to actors. Therefore you always have a use case. A house could have a use case like "House people" and of course several orthogonal nonfunctional requirements like Warming, Rain shield, Wind shield, Size, and so on. "House warming" is a continuous use case. Typically the trigger for continuous use cases is a change of the system state, e.g. the house is habitable. It has no final result, but continuous results. Again the end of a continuous use case is typically triggered by a system change, e.g. house is demolished. A hammer could have the use case "Hammer something". It seems strange to describe use cases for systems like hammer or houses. Although there may be only a few meaningful use cases they put a focus on the real goal of the system.
>
> Tim
>
> Von: sysml...@googlegroups.com [mailto:sysml...@googlegroups.com] Im Auftrag von Baudouin MARTIN
> Gesendet: Samstag, 14. April 2012 19:08
> An: sysml...@googlegroups.com
> Betreff: [Spam.X angeforderte Email: ]Re: [Spam.X angeforderte Email: ][SysML Forum] SysML and building modelling
>
> Hi,
>
> thanks to all for your response. I'm quite new in SysML but I understand this language more and more and I like it.
> Although a use case has a starting point and end points, it could also have a continuous behavior between these points. I would mark those use cases with a stereotype "continuous use case"

> (http://www.sysmod.de/sysmod.profile.en/guidances/supportingmaterials/...).

[Nacho]

On Tue, Apr 17, 2012 at 4:27 PM, Dan George <dgeorg...@gmail.com> wrote:

Tim, wouldn't it be better to put the focus on the goals the user has
for using the system? The system, of course, has no goals; it is the
user who has goals and wants to know how the system affects their
ability to achieve them.

Jack, your "Do no harm" goal is certainly a legitimate goal. I would
be interested to see what you have in mind for the scenarios
associated with that use case goal. It seems like that is a goal that
would be considered when evaluating the scenarios of all use cases. Do
any of the proposed interactions pose a risk to the "Do no harm" goal?

I would like to add my five cents. Maybe "Do no harm" is more a constraint than a requirement (or it is a non functional requirement if you prefer (which at the end is a constraint ;) ))  because it limits the other requirements and the total potential solutions for your system (defined as block, activity, parametric diagrams, etc.) The negative enuntiation of the sentence put me on the track of that difference, hope that helps.

[Tim Weilkiens]

What do you mean with Do not harm? Doesn't sound like a use case.

Tim

-----Original Message-----
From: Jack Ring [jri...@gmail.com]
Received: Mittwoch, 18 Apr. 2012, 6:26
To: sysml...@googlegroups.com [sysml...@googlegroups.com]
Subject: [Spam.X angeforderte Email: ]Re: [SysML Forum] SysML and building modelling

Pls share an example Use Case regarding Do No Harm.

On Apr 15, 2012, at 10:06 PM, Tim Weilkiens wrote:









Every system has a function that is provided to actors. Therefore you always have a use case. A house could have a use case like “House people” and of course several
orthogonal nonfunctional requirements like Warming, Rain shield, Wind shield, Size, and so on. “House warming” is a continuous use case. Typically the trigger for continuous use cases is a change of the system state, e.g. the house is habitable. It has no
final result, but continuous results. Again the end of a continuous use case is typically triggered by a system change, e.g. house is demolished. A hammer could have the use case “Hammer something”. It seems strange to describe use cases for systems like hammer
or houses. Although there may be only a few meaningful use cases they put a focus on the real goal of the system.





Tim










Von: sysml...@googlegroups.com [mailto:sysml...@googlegroups.com] Im
Auftrag von Baudouin MARTIN
Gesendet: Samstag, 14. April 2012 19:08
An: sysml...@googlegroups.com
Betreff: [Spam.X angeforderte Email: ]Re: [Spam.X angeforderte Email: ][SysML Forum] SysML and building modelling






Hi,








thanks to all for your response. I'm quite new in SysML but I understand this language more and more and I like it.




Although a use case has a starting point and end points, it could also have a continuous behavior between these points. I would mark those use cases with a stereotype
“continuous use case”

(http://www.sysmod.de/sysmod.profile.en/guidances/supportingmaterials/Stereotype_usecases_3A98DCB5.html).

[Tim Weilkiens]

Dan,

for me the use cases are a kind of representation of the user goals: "The user wants to <use case name>". The use case is related with the quality requirements. You must always the both sides - the function and the quality of the function.

"Do no harm" is a quality requirement and could not directly translated into a use case.

Tim

-----Original Message-----
From: sysml...@googlegroups.com [mailto:sysml...@googlegroups.com] On Behalf Of Dan George
Sent: Tuesday, April 17, 2012 4:27 PM
To: SysML Forum
Subject: [Spam.X angeforderte Email: ][SysML Forum] Re: SysML and building modelling

Tim, wouldn't it be better to put the focus on the goals the user has for using the system? The system, of course, has no goals; it is the user who has goals and wants to know how the system affects their ability to achieve them.

Jack, your "Do no harm" goal is certainly a legitimate goal. I would be interested to see what you have in mind for the scenarios associated with that use case goal. It seems like that is a goal that would be considered when evaluating the scenarios of all use cases. Do any of the proposed interactions pose a risk to the "Do no harm" goal?

Goal: Do no harm

Scenario A - precondition: the system is in "safe mode"
1. user points system at foot
2. user commands system to fire
3. system ignores command
4. user moves on to next potentially harmful scenario

Scenario B
...
Scenario ZZ
...

Perhaps there is a better choice of goals to elaborate and still describe system interactions in a way that validates safe operation.
The are an infinite number of equally acceptable ways to not do something.

Dan

Dan

On Apr 15, 10:06 pm, Tim Weilkiens <Tim.Weilki...@oose.de> wrote:

> Every system has a function that is provided to actors. Therefore you always have a use case. A house could have a use case like "House people" and of course several orthogonal nonfunctional requirements like Warming, Rain shield, Wind shield, Size, and so on. "House warming" is a continuous use case. Typically the trigger for continuous use cases is a change of the system state, e.g. the house is habitable. It has no final result, but continuous results. Again the end of a continuous use case is typically triggered by a system change, e.g. house is demolished. A hammer could have the use case "Hammer something". It seems strange to describe use cases for systems like hammer or houses. Although there may be only a few meaningful use cases they put a focus on the real goal of the system.
>
> Tim
>
> Von: sysml...@googlegroups.com [mailto:sysml...@googlegroups.com]
> Im Auftrag von Baudouin MARTIN
> Gesendet: Samstag, 14. April 2012 19:08
> An: sysml...@googlegroups.com
> Betreff: [Spam.X angeforderte Email: ]Re: [Spam.X angeforderte Email:
> ][SysML Forum] SysML and building modelling
>
> Hi,
>
> thanks to all for your response. I'm quite new in SysML but I understand this language more and more and I like it.
> Although a use case has a starting point and end points, it could also have a continuous behavior between these points. I would mark those use cases with a stereotype "continuous use case"

> (http://www.sysmod.de/sysmod.profile.en/guidances/supportingmaterials/...).

[José Borbinha]

IMHO we really should separate the concerns on "function" from concerns on
"quality".

Saying this is a more generic way, and relating to use cases, a use case
should concern only with "black-box" functional requirements (what a user
expects from the system or has to do in order to interact with it -please be
aware that the actor itself does not need to be aware of that, as for
example when we pass by a photoelectric cellule that just counts passages,
of which we even are not aware...).

Everything "white-box", and especially non-functional (and usually quality
requirements are like that) should not be concerns expressed in use cases.

IMHO we can conceive "business rules", that can be expressed (or from which
we can derive) either functional or non-functional requirements, but that
might not be relevant for a use case.
I'm not aware of this particular case of "not arm", but in general this
seems to me a business rule of that kind, that might be expressed in one or
more requirements, but which traceability in the model might be better done
to entities or parametrics in the model domain, as for example, "the cables
must be duplicated...", or even in the behavior "white-box", as for example
"when moving rear, the machine must sound a noise", or "the machine only
engages in a rear movement after the operator pushes a button that must be
located on the back of the cabin, so this way it can be assured the operator
have looked back before moving the machine".

This last example is a business rule with many functional and non-functional
requirements, but all this could simply be, in the description of a use case
scenario, a unique step like "the user moves the machine back", leaving all
the details of the realization of the scenario to the domain model ("the
button must be on the back of the cabin...") or activity/sequence models
("...turn back... push button... turn front... engage gear...").

IMHO, it is a common mistake (off course, only a "conceptual mistake", not a
technical one... the world is full of bad, but still working systems, after
all...) to model too detailed use cases, involving concerns that are not
more relevant of other views than of that (this is where the concepts of
"white/back box" are especially relevant).

In my understanding that might come from the "UML school" (I "was born there
;-) , where the fact that requirements are not part of the architecture
being developed (there are no requirements models in UML...) motivates
people to model each concern (=requirement) in the first opportunity they
find in the models for that (which usually is the use case diagram...).
Fortunately, in SysML you can have requirements diagrams, so now you just
need the cold blood to say, in the early stages of the modeling, "OK, this
is a requirement, but I understand that I'll have until the end of the
modeling to realize it, so no need to hurry"...)

I'm teaching a course on "Modeling" for computer engineering students, where
we address UML and SysML side by side, and one assignment for the students
is a project that lasts all the semester, but they have to do in several
steps (so we can feedback them). After a few years of bad experiences with
issues like these, we realized that the best would be to release the UoD
(universe of discourse) to the students by phases, and not all on the same
time, so we could guide them on this "thinking path" (we have no time to
teach methods (***)). This way, we first release a partial UoD that
motivates them model the use cases properly, and only after that we release
them the other details of the business rules (which they like, as it also
makes a parallel with the express methods they learned in sw engineering,
thus proving that modeling is not relevant to only waterfall methods ;-)

----------------
(***) We use in class Tim's book, but we expressly ask the students to
ignore SYGMOD... sorry Tim, your method is fine for SysML, but it can be
confusing for not skilled practitioners if on the same time they have to
learn UML and use UML and SysML all together... -so we use what I call the
"ad hoc method", just for teaching (they also can have other courses latter
on more focused on methods).

Best!
José Borbinha

[Robert Halligan]

Jack

Wow, what a response. Do I read it right – that you consider that it is a function of a house brick to not emit lethal amounts of X-radiation? Please show us the corresponding use case. How would you include the infinite number of other “not do”s in your use case?

What do you mean regarding “I got the idea that a use case can request only a function”? I said nothing about a use case requesting a function. I have never seen a use case request anything. Describe intent or reality regarding use, yes. Request, no.

Can you please explain where you got the idea that to not do something is a function? Which dictionary or other reference do you use?

Robert

On 17/04/12 3:02 PM, "Jack Ring" <jri...@gmail.com> wrote:

Robert,
Wow, what a claim.
Pls tell us what you think a resilient system does for its user.
Then tell us how you would request resilient behavior in a use case.
Then tell us where you got the idea that a use case can request only a function.
Jack
On Apr 16, 2012, at 8:01 PM, Robert Halligan wrote:

[SysML Forum] SysML and building modelling

[Jack Ring]

Robert,
Regarding "I said nothing about a use case requesting a function." pls see your previous " ...is not a function, and cannot therefore be the subject of a use case."
Meanwhile, I have not equated use case with function. The "function" idea was introduced by others on this list.
I asked "tell us how you would request resilient behavior in a use case." Pls notice 'behavior.'
If you want to use bricks and functions and other notions to tell us, then so be it, but don't claim I said any such thing.

Do you care to tell us what a resilient system does for a user and how you would express that in a use case?
Apparently, now, it would be helpful to describe which version of "use case" you are presuming.

Jack

[Dan George]

José,

The UML does provide the facility to specify requirements. In fact, that is all it does. If an end item is constructed and it does not conform to the model then it is defective. Most people do not use the UML this way because they trust 3GL languages more. Since this is a SysML forum, you can think of the traditional schematic, 3-D model, assembly drawings, etc. as the equivalent to 3GL programming languages. SysML provides a higher level of abstraction that is still definitive. Similar to UML usage, most people only use SysML as a notional description and rely on the traditional documents as the definitive requirements.

The SysML requirements model doesn't actually describe the system but provides formal relationships between the concise model elements and the natural language description of a system. The requirements model helps to organize those natural language statements and relate them to the other model elements. This facility is not essential but is certainly a good idea. It helps maintain consistency between the abstract intent, expressed in natural language, and the definitive SysML model. However, it is essentially just a way to "show your work" and not a means of specification of the actual end item.

My statements are off topic and but José triggered these thoughts and I hope the group doesn't mind my sharing them.

Cheers,

Dan

> sysmlforum+unsubscribe@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.
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+unsubscribe@googlegroups.com

For more options, visit this group at
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.
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+unsubscribe@googlegroups.com

[Jack Ring]

Robert, 

Have you caught on yet?

That’s why Ma Bell invented the busy signal.

That’s why Test Ranges have range safety systems.

That’s why autonomous vehicles have fratricide prevention.

Jack

On Apr 16, 2012, at 8:01 PM, Robert Halligan <rhal...@ppi-int.com> wrote:

Jack, “do no harm” is not a function, and cannot therefore be the subject of a use case.

Robert

--
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