Issue 18760: actors of a use case express the requirements of its subject(s) regarding its/their environment. (uml25-ftf) Source: EADS (Mr. Yves Bernard, yves.bernard(at)airbus.com) Nature: Uncategorized Issue Severity: Summary: Quoted from §18.1.3, p686: “An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.” There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about “actor’s needs/requirements” in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment. Resolution: Revised Text: Actions taken: June 6, 2013: received issue Discussion: End of Annotations:===== m: "BERNARD, Yves" To: Juergen Boldt Date: Thu, 6 Jun 2013 16:43:33 +0200 Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 Thread-Topic: [UML 2.5 FTF] ballot 6: issue 18726 Thread-Index: Ac5iv3RyEnTpeI4KRmafa6UIo+er9wABK8BA Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Hi Juergen, Yes, it is. Thanks Yves From: Juergen Boldt [mailto:juergen@omg.org] Sent: jeudi 6 juin 2013 16:09 To: BERNARD, Yves Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 Yves, so this is the new issue? -Juergen At 10:03 AM 6/6/2013, you wrote: Steve, Ok to create a new issue for this. Quoted from §18.1.3, p686: .An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.. There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about .actor.s needs/requirements. in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment. Yves Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Chonoles, Michael J" To: "Steve.Cook@microsoft.com" , "BERNARD, Yves" , "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 Thread-Topic: [UML 2.5 FTF] ballot 6: issue 18726 Thread-Index: Ac5itBdvvDNdZG6/SgC4BJ7vdkxFogABLYbAAAFhQkA= Date: Thu, 6 Jun 2013 14:04:10 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.186.156.82] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-06-06_06:2013-06-06,2013-06-06,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org In addition, the .roles. of the actors is not particular useful, as an Actor is not a person, it is a role that one or more people can play (of course, not only a person.) Now there are some actors that don.t have needs, sometimes called secondary actors, but I believe the existing text is sufficient Michael From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, June 06, 2013 9:35 AM To: BERNARD, Yves; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] ballot 6: issue 18726 Yves This particular wording - .de.ned according to the needs of Actors. - comes from before and has nothing to do with the topic of the issue. The resolution to 18726 does not introduce or change this phrase; its appearance in the resolution text is purely ancillary and contextual, and it could be replaced by .... without affecting the resolution.< In any case I disagree with you: .according to the roles of Actors. makes no sense to me, whereas the current text does make some sense. If you feel this wording needs to be changed, that would be a separate issue, and I think you would have to explain why Actors do not have needs, given that UseCases are all about specifying requirements. .Needs. and .requirements. are pretty much synonyms, and I think this phrase explains that the overall requirements are partitioned according to the requirements (needs) that relate to particular Actors. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 06 June 2013 13:48 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot 6: issue 18726 About UseCase description. The new text proposed for §18.1.1 includes the following sentence: .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the needs of Actors.. Actors not always have particular .needs. regarding the subject of the UseCase. I suggest replacing this sentence by .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the roles of Actors.. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Chonoles, Michael J" To: "Yves.Bernard@airbus.com" , Steve Cook , "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 Thread-Topic: [UML 2.5 FTF] ballot 6: issue 18726 Thread-Index: Ac5itBdvvDNdZG6/SgC4BJ7vdkxFogABLYbAAADKgCAAALb1kA== Date: Thu, 6 Jun 2013 14:10:56 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.186.156.82] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-06-06_06:2013-06-06,2013-06-06,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org While there are always special cases, use case theory, of which there are many books on this, consistency state that the use case is a set of purposes for which an actor wishes the system to perform or help him with. Detaching use cases from the needs/wishes/goals of the actors will have significant methodological consequences. Now, it.s possible that some particular methodology will occasionally use the use case form to capture behaviors that don.t really have goal-oriented actors (e.g., environment, time, maintenance), though it.s usually possible to figure out who the real actor is in such cases. I would not recommend a change here. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 10:03 AM To: Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] ballot 6: issue 18726 Steve, Ok to create a new issue for this. Quoted from §18.1.3, p686: .An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.. There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about .actor.s needs/requirements. in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment. Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 6 juin 2013 15:35 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 Yves This particular wording - .de.ned according to the needs of Actors. - comes from before and has nothing to do with the topic of the issue. The resolution to 18726 does not introduce or change this phrase; its appearance in the resolution text is purely ancillary and contextual, and it could be replaced by .... without affecting the resolution. In any case I disagree with you: .according to the roles of Actors. makes no sense to me, whereas the current text does make some sense. If you feel this wording needs to be changed, that would be a separate issue, and I think you would have to explain why Actors do not have needs, given that UseCases are all about specifying requirements. .Needs. and .requirements. are pretty much synonyms, and I think this phrase explains that the overall requirements are partitioned according to the requirements (needs) that relate to particular Actors. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 06 June 2013 13:48 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot 6: issue 18726 About UseCase description. The new text proposed for §18.1.1 includes the following sentence: .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the needs of Actors.. Actors not always have particular .needs. regarding the subject of the UseCase. I suggest replacing this sentence by .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the roles of Actors.. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "BERNARD, Yves" To: "Chonoles, Michael J" , Steve Cook , "uml25-ftf@omg.org" Date: Thu, 6 Jun 2013 18:24:29 +0200 Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Topic: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Index: Ac5itBdvvDNdZG6/SgC4BJ7vdkxFogABLYbAAADKgCAAALb1kAADuObA Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Michael, To me an entity who/which has needs/whishes/requirements/goals is a stakeholder. A stakeholder can be an uml::Actor of the system of interest or not. It is if it has some interactions with the system (in the frame of a particular use case) and it is not otherwise. I agree that in most cases entities which are stakeholders are uml::Actors as well but nothing implies this since each concept has its own definition and they are unrelated. Examples: · Airworthiness authorities are stakeholders for any Avionics System we develop (and so they have requirements about them) but they are not uml::Actors for any of them (there is no use case where they have some interaction with the system). · Flights parameters are provided by some Avionics Computers are also used by systems from .the Open World. domain (cabin) to display flight information to the passengers. Thus some avionics computer systems are uml::Actors for the open world.s systems but they are not stakeholder of them they get no added value from them and has no requirement about them because it has no need of them. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: jeudi 6 juin 2013 16:11 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 While there are always special cases, use case theory, of which there are many books on this, consistency state that the use case is a set of purposes for which an actor wishes the system to perform or help him with. Detaching use cases from the needs/wishes/goals of the actors will have significant methodological consequences. Now, it.s possible that some particular methodology will occasionally use the use case form to capture behaviors that don.t really have goal-oriented actors (e.g., environment, time, maintenance), though it.s usually possible to figure out who the real actor is in such cases. I would not recommend a change here. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 10:03 AM To: Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] ballot 6: issue 18726 Steve, Ok to create a new issue for this. Quoted from §18.1.3, p686: .An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.. There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about .actor.s needs/requirements. in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment. Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 6 juin 2013 15:35 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 Yves This particular wording - .de.ned according to the needs of Actors. - comes from before and has nothing to do with the topic of the issue. The resolution to 18726 does not introduce or change this phrase; its appearance in the resolution text is purely ancillary and contextual, and it could be replaced by .... without affecting the resollution. In any case I disagree with you: .according to the roles of Actors. makes no sense to me, whereas the current text does make some sense. If you feel this wording needs to be changed, that would be a separate issue, and I think you would have to explain why Actors do not have needs, given that UseCases are all about specifying requirements. .Needs. and .requirements. are pretty much synonyms, and I think this phrase explains that the overall requirements are partitioned according to the requirements (needs) that relate to particular Actors. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 06 June 2013 13:48 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot 6: issue 18726 About UseCase description. The new text proposed for §18.1.1 includes the following sentence: .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the needs of Actors.. Actors not always have particular .needs. regarding the subject of the UseCase. I suggest replacing this sentence by .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the roles of Actors.. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Chonoles, Michael J" To: "BERNARD, Yves" , Steve Cook , "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Topic: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Index: AQHOYtJWArTAdJydlEu6DnprzJF8TJkqS9YA Date: Fri, 7 Jun 2013 14:31:57 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.186.156.82] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-06-07_06:2013-06-07,2013-06-07,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org In almost all cases where you have an actor who is not a stakeholder, you either have 1) An intermediary, who transfers information to/from a stakeholder. For example, we don.t usually include terminals and keyboards as actors 2) A worker, who is really a design element, and are part of the entire system. For example, data-entry people are replaceable, in theory, by robots or other automation, and have no independent goals. They ultimately are a variety of intermediary above. We can often completely design or eliminate their system interaction if we wish. 3) External systems, whose owners and stakeholders, are the represented by the external system actor. 4) Passive external systems, databases, people, etc. They are queried by the subject systems, but don.t have any independent goals. These are sometimes called secondary actors, as they are usally contacted by the system to when a use case is triggered by a primary actor who actually has a goal. 5) Environmental triggers, where the setters of the threshold for the trigger is the setter. For example, an air condition turning on based on rising temperature or an alarm clock ringing because a time has been reached, while might be diagrammed as environment or time as the actor, but they are proxies for the actor who sets the temperature / time for the trigger . who really has the goals So, there are some actors or roles that may be modeled as actors that may not have direct goals, But for each use case (perhaps with some very rare exceptions) have some primary actor who either has the goals, or acts a proxy for the actor/stakeholder with the goals. There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 12:24 PM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Michael, To me an entity who/which has needs/whishes/requirements/goals is a stakeholder. A stakeholder can be an uml::Actor of the system of interest or not. It is if it has some interactions with the system (in the frame of a particular use case) and it is not otherwise. I agree that in most cases entities which are stakeholders are uml::Actors as well but nothing implies this since each concept has its own definition and they are unrelated. Examples: · Airworthiness authorities are stakeholders for any Avionics System we develop (and so they have requirements about them) but they are not uml::Actors for any of them (there is no use case where they have some interaction with the system). · Flights parameters are provided by some Avionics Computers are also used by systems from .the Open World. domain (cabin) to display flight information to the passengers. Thus some avionics computer systems are uml::Actors for the open world.s systems but they are not stakeholder of them they get no added value from them and has no requirement about them because it has no need of them. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: jeudi 6 juin 2013 16:11 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 While there are always special cases, use case theory, of which there are many books on this, consistency state that the use case is a set of purposes for which an actor wishes the system to perform or help him with. Detaching use cases from the needs/wishes/goals of the actors will have significant methodological consequences. Now, it.s possible that some particular methodology will occasionally use the use case form to capture behaviors that don.t really have goal-oriented actors (e.g., environment, time, maintenance), though it.s usually possible to figure out who the real actor is in such cases. I would not recommend a change here. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 10:03 AM To: Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] ballot 6: issue 18726 Steve, Ok to create a new issue for this. Quoted from §18.1.3, p686: .An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.. There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about .actor.s needs/requirements. in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment. Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 6 juin 2013 15:35 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 Yves This particular wording - .de.ned according to the needs of Actors. - comes from before and has nothing to do with the topic of the issue. The resolution to 18726 does not introduce or change this phrase; its appearance in the resolution text is purely ancillary and contextual, and it could be replaced by ..... without affecting the resolution. In any case I disagree with you: .according to the roles of Actors. makes no sense to me, whereas the current text does make some sense. If you feel this wording needs to be changed, that would be a separate issue, and I think you would have to explain why Actors do not have needs, given that UseCases are all about specifying requirements. .Needs. and .requirements. are pretty much synonyms, and I think this phrase explains that the overall requirements are partitioned according to the requirements (needs) that relate to particular Actors. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 06 June 2013 13:48 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot 6: issue 18726 About UseCase description. The new text proposed for §18.1.1 includes the following sentence: .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the needs of Actors.. Actors not always have particular .needs. regarding the subject of the UseCase. I suggest replacing this sentence by .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the roles of Actors.. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "BERNARD, Yves" To: "Chonoles, Michael J" , Steve Cook , "uml25-ftf@omg.org" Date: Fri, 7 Jun 2013 17:32:05 +0200 Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Topic: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Index: AQHOYtJWArTAdJydlEu6DnprzJF8TJkqS9YAgAAU0gA= Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Michael, So, according to your last sentence: .There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. and since the actors are those (external) entities participating to use cases, you finally agree that the .needs. according to which these use cases are defined cannot be restricted to those of their actors and thus that §18.1.1 should be modified, don.t you? Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: vendredi 7 juin 2013 16:32 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) In almost all cases where you have an actor who is not a stakeholder, you either have 1) An intermediary, who transfers information to/from a stakeholder. For example, we don.t usually include terminals and keyboards as actors 2) A worker, who is really a design element, and are part of the entire system. For example, data-entry people are replaceable, in theory, by robots or other automation, and have no independent goals. They ultimately are a variety of intermediary above. We can often completely design or eliminate their system interaction if we wish. 3) External systems, whose owners and stakeholders, are the represented by the external system actor. 4) Passive external systems, databases, people, etc. They are queried by the subject systems, but don.t have any independent goals. These are sometimes called secondary actors, as they are usally contacted by the system to when a use case is triggered by a primary actor who actually has a goal. 5) Environmental triggers, where the setters of the threshold for the trigger is the setter. For example, an air condition turning on based on rising temperature or an alarm clock ringing because a time has been reached, while might be diagrammed as environment or time as the actor, but they are proxies for the actor who sets the temperature / time for the trigger . who really has the goals So, there are some actors or roles that may be modeled as actors that may not have direct goals, But for each use case (perhaps with some very rare exceptions) have some primary actor who either has the goals, or acts a proxy for the actor/stakeholder with the goals. There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 12:24 PM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Michael, To me an entity who/which has needs/whishes/requirements/goals is a stakeholder. A stakeholder can be an uml::Actor of the system of interest or not. It is if it has some interactions with the system (in the frame of a particular use case) and it is not otherwise. I agree that in most cases entities which are stakeholders are uml::Actors as well but nothing implies this since each concept has its own definition and they are unrelated. Examples: · Airworthiness authorities are stakeholders for any Avionics System we develop (and so they have requirements about them) but they are not uml::Actors for any of them (there is no use case where they have some interaction with the system). · Flights parameters are provided by some Avionics Computers are also used by systems from .the Open World. domain (cabin) to display flight information to the passengers. Thus some avionics computer systems are uml::Actors for the open world.s systems but they are not stakeholder of them they get no added value from them and has no requirement about them because it has no need of them. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: jeudi 6 juin 2013 16:11 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 While there are always special cases, use case theory, of which there are many books on this, consistency state that the use case is a set of purposes for which an actor wishes the system to perform or help him with. Detaching use cases from the needs/wishes/goals of the actors will have significant methodological consequences. Now, it.s possible that some particular methodology will occasionally use the use case form to capture behaviors that don.t really have goal-oriented actors (e.g., environment, time, maintenance), though it.s usually possible to figure out who the real actor is in such cases. I would not recommend a change here. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 10:03 AM To: Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] ballot 6: issue 18726 Steve, Ok to create a new issue for this. Quoted from §18.1.3, p686: .An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.. There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about .actor.s needs/requirements. in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment. Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 6 juin 2013 15:35 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 Yves This particular wording - .de.ned according to the needs of Actors. - comes from before and has nothing to do with the topic of the issue. The resolution to 18726 does not introduce or change this phrase; its appearance in the resolution text is purely ancillary and contextual, and it could be replaced by .... without afffecting the resolution. In any case I disagree with you: .according to the roles of Actors. makes no sense to me, whereas the current text does make some sense. If you feel this wording needs to be changed, that would be a separate issue, and I think you would have to explain why Actors do not have needs, given that UseCases are all about specifying requirements. .Needs. and .requirements. are pretty much synonyms, and I think this phrase explains that the overall requirements are partitioned according to the requirements (needs) that relate to particular Actors. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 06 June 2013 13:48 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot 6: issue 18726 About UseCase description. The new text proposed for §18.1.1 includes the following sentence: .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the needs of Actors.. Actors not always have particular .needs. regarding the subject of the UseCase. I suggest replacing this sentence by .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the roles of Actors.. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Manfred R. Koethe" Subject: Re: [UML 2.5 FTF] issue 18760 (was 18726) Date: Sun, 9 Jun 2013 12:35:51 -0400 To: "uml25-ftf@omg.org" X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:tMkiibzW3KCEcSVMdxTXIBLXFev9HABxFWrP4Ep11AM 0bmc13rrkv22WZXDUqpaQAAuAMp967XjI8x0VdYwuwFk5W4nON l/TiwWL08QEfH8kPjHsEIQJb3t/eN2fPUBdUJI3gK/033hENgR Y0cU1lYSW7TSed+CWVVNjraGaVlvOXLVUlEvUR9vLMJfEBCO3K K30857uV3oxTMac6fQBGl4gwg8kJkNo/4+poRLyIdEQdOWdsqj HNoZ/Bd3fgRg+pexT62Fj9dQ2GuQLUKix588r52I1MlPwYAfWX qWUNAEcqThtEPtqxCmLNVPEsvxXuPxHTqAUIx99EaYopen+btn HD/ooxyAARKkTmkLsuPLVhIhQ8YMYg0OT2QRAo/UDQlC8zlx3M 8pFyWSZfXi0nA== X-Virus-Scanned: amavisd-new at omg.org Sorry coming late to the discussion. I think the previous discussion tried to interpret too much power and functionality into the Actor. By definition an Actor is just an entity that is *outside* the system and its only means of interacting with the system is by exchanging information along the System-boundary-crossing Association between Actor and UseCase. This information flow *may* influence the behavior represented by the UseCase, and thus the behavior of the System. But the "interaction" might also be totally observatory where the Actor is receiving information pushed out from the UseCase. In that case the System might even be totally unaware of the Actor's existence. I think we should just state this fact of an Actor being an outside entity interacting with the System by means of information flowing along an Association between Actor and one or more UseCases, and abstain from any further interpretation into that like needs, stake holders, roles, etc. It might be worth to mention that this kind of interaction aids the discovery of all required interfaces to be provided by the System. Kind regards, Manfred On Jun 7, 2013, at 11:32 , "BERNARD, Yves" wrote: Michael, So, according to your last sentence: âThere is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use caseâ and since the actors are those (external) entities participating to use cases, you finally agree that the âneedsâ according to which these use cases are defined cannot be restricted to those of their actors and thus that §18.1.1 should be modified, donât you? Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: vendredi 7 juin 2013 16:32 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) In almost all cases where you have an actor who is not a stakeholder, you either have 1) An intermediary, who transfers information to/from a stakeholder. For example, we donât usually include terminals and keyboards as actors 2) A worker, who is really a design element, and are part of the entire system. For example, data-entry people are replaceable, in theory, by robots or other automation, and have no independent goals. They ultimately are a variety of intermediary above. We can often completely design or eliminate their system interaction if we wish. 3) External systems, whose owners and stakeholders, are the represented by the external system actor. 4) Passive external systems, databases, people, etc. They are queried by the subject systems, but donât have any independent goals. These are sometimes called secondary actors, as they are usally contacted by the system to when a use case is triggered by a primary actor who actually has a goal. 5) Environmental triggers, where the setters of the threshold for the trigger is the setter. For example, an air condition turning on based on rising temperature or an alarm clock ringing because a time has been reached, while might be diagrammed as environment or time as the actor, but they are proxies for the actor who sets the temperature / time for the trigger . who really has the goals So, there are some actors or roles that may be modeled as actors that may not have direct goals, But for each use case (perhaps with some very rare exceptions) have some primary actor who either has the goals, or acts a proxy for the actor/stakeholder with the goals. There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 12:24 PM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Michael, To me an entity who/which has needs/whishes/requirements/goals is a stakeholder. A stakeholder can be an uml::Actor of the system of interest or not. It is if it has some interactions with the system (in the frame of a particular use case) and it is not otherwise. I agree that in most cases entities which are stakeholders are uml::Actors as well but nothing implies this since each concept has its own definition and they are unrelated. Examples: · Airworthiness authorities are stakeholders for any Avionics System we develop (and so they have requirements about them) but they are not uml::Actors for any of them (there is no use case where they have some interaction with the system). · Flights parameters are provided by some Avionics Computers are also used by systems from âthe Open Worldâ domain (cabin) to display flight information to the passengers. Thus some avionics computer systems are uml::Actors for the open worldâs systems but they are not stakeholder of them they get no added value from them and has no requirement about them because it has no need of them. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: jeudi 6 juin 2013 16:11 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 While there are always special cases, use case theory, of which there are many books on this, consistency state that the use case is a set of purposes for which an actor wishes the system to perform or help him with. Detaching use cases from the needs/wishes/goals of the actors will have significant methodological consequences. Now, itâs possible that some particular methodology will occasionally use the use case form to capture behaviors that donât really have goal-oriented actors (e.g., environment, time, maintenance), though itâs usually possible to figure out who the real actor is in such cases. I would not recommend a change here. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 10:03 AM To: Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] ballot 6: issue 18726 Steve, Ok to create a new issue for this. Quoted from §18.1.3, p686: âAn Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.â There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about âactorâs needs/requirementsâ in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment. Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 6 juin 2013 15:35 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 Yves This particular wording - âdeï¬ned according to the needs of Actorsâ - comes from before and has nothing to do with the topic of the issue. The resolution to 18726 does not introduce or change this phrase; its appearance in the resolution text is purely ancillary and contextual, and it could be replaced by â..â without affecting the resolution. In any case I disagree with you: âaccording to the roles of Actorsâ makes no sense to me, whereas the current text does make some sense. If you feel this wording needs to be changed, that would be a separate issue, and I think you would have to explain why Actors do not have needs, given that UseCases are all about specifying requirements. âNeedsâ and ârequirementsâ are pretty much synonyms, and I think this phrase explains that the overall requirements are partitioned according to the requirements (needs) that relate to particular Actors. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 06 June 2013 13:48 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot 6: issue 18726 About UseCase description. The new text proposed for §18.1.1 includes the following sentence: âThe required behavior of the subject is speciï¬ed by one or more UseCases, which are deï¬ned according to the needs of Actors.â Actors not always have particular âneedsâ regarding the subject of the UseCase. I suggest replacing this sentence by âThe required behavior of the subject is speciï¬ed by one or more UseCases, which are deï¬ned according to the roles of Actors.â Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Date: Mon, 10 Jun 2013 07:04:43 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Index: Ac5lL3dThRgLFXbLQZOgMeRLH1k9LAAazvOQ From: "Pete Rivett" To: "Manfred R. Koethe" , X-Virus-Scanned: amavisd-new at omg.org .Outside the system. is problematic when the overall (set of) models is a system composed of many (sub-)systems where what is external to one is internal to another. We should have something to state how, for example, a Realization could be used to link a Class within an external modeled system to an external Actor. Probably a separate issue though . do we have one covering this? Also the new text still AFAIK retains the following which does not fit with your point that a system may not know about the actor (in which case it cannot be said to collaborate with it) A UseCase is a kind of BehavioredClassifier that represents a declaration of a set of offered Behaviors. Each UseCase specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more Actors. Pete From: Manfred R. Koethe [mailto:koethe@88solutions.com] Sent: Sunday, June 09, 2013 9:36 AM To: uml25-ftf@omg.org Subject: Re: [UML 2.5 FTF] issue 18760 (was 18726) Sorry coming late to the discussion. I think the previous discussion tried to interpret too much power and functionality into the Actor. By definition an Actor is just an entity that is *outside* the system and its only means of interacting with the system is by exchanging information along the System-boundary-crossing Association between Actor and UseCase. This information flow *may* influence the behavior represented by the UseCase, and thus the behavior of the System. But the "interaction" might also be totally observatory where the Actor is receiving information pushed out from the UseCase. In that case the System might even be totally unaware of the Actor's existence. I think we should just state this fact of an Actor being an outside entity interacting with the System by means of information flowing along an Association between Actor and one or more UseCases, and abstain from any further interpretation into that like needs, stake holders, roles, etc. It might be worth to mention that this kind of interaction aids the discovery of all required interfaces to be provided by the System. Kind regards, Manfred On Jun 7, 2013, at 11:32 , "BERNARD, Yves" wrote: Michael, So, according to your last sentence: .There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. and since the actors are those (external) entities participating to use cases, you finally agree that the .needs. according to which these use cases are defined cannot be restricted to those of their actors and thus that §18.1.1 should be modified, don.t you? Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: vendredi 7 juin 2013 16:32 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) In almost all cases where you have an actor who is not a stakeholder, you either have 1) An intermediary, who transfers information to/from a stakeholder. For example, we don.t usually include terminals and keyboards as actors 2) A worker, who is really a design element, and are part of the entire system. For example, data-entry people are replaceable, in theory, by robots or other automation, and have no independent goals. They ultimately are a variety of intermediary above. We can often completely design or eliminate their system interaction if we wish. 3) External systems, whose owners and stakeholders, are the represented by the external system actor. 4) Passive external systems, databases, people, etc. They are queried by the subject systems, but don.t have any independent goals. These are sometimes called secondary actors, as they are usally contacted by the system to when a use case is triggered by a primary actor who actually has a goal. 5) Environmental triggers, where the setters of the threshold for the trigger is the setter. For example, an air condition turning on based on rising temperature or an alarm clock ringing because a time has been reached, while might be diagrammed as environment or time as the actor, but they are proxies for the actor who sets the temperature / time for the trigger . who really has the goaals So, there are some actors or roles that may be modeled as actors that may not have direct goals, But for each use case (perhaps with some very rare exceptions) have some primary actor who either has the goals, or acts a proxy for the actor/stakeholder with the goals. There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 12:24 PM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Michael, To me an entity who/which has needs/whishes/requirements/goals is a stakeholder. A stakeholder can be an uml::Actor of the system of interest or not. It is if it has some interactions with the system (in the frame of a particular use case) and it is not otherwise. I agree that in most cases entities which are stakeholders are uml::Actors as well but nothing implies this since each concept has its own definition and they are unrelated. Examples: · Airworthiness authorities are stakeholders for any Avionics System we develop (and so they have requirements about them) but they are not uml::Actors for any of them (there is no use case where they have some interaction with the system). · Flights parameters are provided by some Avionics Computers are also used by systems from .the Open World. domain (cabin) to display flight information to the passengers. Thus some avionics computer systems are uml::Actors for the open world.s systems but they are not stakeholder of them they get no added value from them and has no requirement about them because it has no need of them. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: jeudi 6 juin 2013 16:11 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 While there are always special cases, use case theory, of which there are many books on this, consistency state that the use case is a set of purposes for which an actor wishes the system to perform or help him with. Detaching use cases from the needs/wishes/goals of the actors will have significant methodological consequences. Now, it.s possible that some particular methodology will occasionally use the use case form to capture behaviors that don.t really have goal-oriented actors (e.g., environment, time, maintenance), though it.s usually possible to figure out who the real actor is in such cases. I would not recommend a change here. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 10:03 AM To: Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] ballot 6: issue 18726 Steve, Ok to create a new issue for this. Quoted from §18.1.3, p686: .An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.. There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about .actor.s needs/requirements. in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment. Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 6 juin 2013 15:35 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 Yves This particular wording - .de.ned according to the needs of Actors. - comes from before and has nothing to do with the topic of the issue. The resolution to 18726 does not introduce or change this phrase; its appearance in the resolution text is purely ancillary and contextual, and it could be replaced by .... without affecting the resolution. In any case I disagree with you: .according to the roles of Actors. makes no sense to me, whereas the current text does make some sense. If you feel this wording needs to be changed, that would be a separate issue, and I think you would have to explain why Actors do not have needs, given that UseCases are all about specifying requirements. .Needs. and .requirements. are pretty much synonyms, and I think this phrase explains that the overall requirements are partitioned according to the requirements (needs) that relate to particular Actors. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 06 June 2013 13:48 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot 6: issue 18726 About UseCase description. The new text proposed for §18.1.1 includes the following sentence: .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the needs of Actors.. Actors not always have particular .needs. regarding the subject of the UseCase. I suggest replacing this sentence by .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the roles of Actors.. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- From: "Chonoles, Michael J" To: "BERNARD, Yves" , Steve Cook , "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Topic: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Index: AQHOYtJWArTAdJydlEu6DnprzJF8TJkqS9YAgAAU0gCABKvMgA== Date: Mon, 10 Jun 2013 14:49:38 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.186.156.82] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-06-10_03:2013-06-10,2013-06-10,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org Well, I.m not recommending that the sentence be changed. There is some leeway interpretation of the sentence: .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the needs of Actors.. The Use Cases are correctly defined according to the needs of Actors. However, the sources of the details of the requirements could be other stakeholders. Still they should be all defined according to the needs of the primary Actors, e.g., using the actor terminology. michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, June 07, 2013 11:32 AM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Michael, So, according to your last sentence: .There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. and since the actors are those (external) entities participating to use cases, you finally agree that the .needs. according to which these use cases are defined cannot be restricted to those of their actors and thus that §18.1.1 should be modified, don.t you? Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: vendredi 7 juin 2013 16:32 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) In almost all cases where you have an actor who is not a stakeholder, you either have 1) An intermediary, who transfers information to/from a stakeholder. For example, we don.t usually include terminals and keyboards as actors 2) A worker, who is really a design element, and are part of the entire system. For example, data-entry people are replaceable, in theory, by robots or other automation, and have no independent goals. They ultimately are a variety of intermediary above. We can often completely design or eliminate their system interaction if we wish. 3) External systems, whose owners and stakeholders, are the represented by the external system actor. 4) Passive external systems, databases, people, etc. They are queried by the subject systems, but don.t have any independent goals. These are sometimes called secondary actors, as they are usally contacted by the system to when a use case is triggered by a primary actor who actually has a goal. 5) Environmental triggers, where the setters of the threshold for the trigger is the setter. For example, an air condition turning on based on rising temperature or an alarm clock ringing because a time has been reached, while might be diagrammed as environment or time as the actor, but they are proxies for the actor who sets the temperature / time for the trigger . who really has the goalss So, there are some actors or roles that may be modeled as actors that may not have direct goals, But for each use case (perhaps with some very rare exceptions) have some primary actor who either has the goals, or acts a proxy for the actor/stakeholder with the goals. There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 12:24 PM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Michael, To me an entity who/which has needs/whishes/requirements/goals is a stakeholder. A stakeholder can be an uml::Actor of the system of interest or not. It is if it has some interactions with the system (in the frame of a particular use case) and it is not otherwise. I agree that in most cases entities which are stakeholders are uml::Actors as well but nothing implies this since each concept has its own definition and they are unrelated. Examples: · Airworthiness authorities are stakeholders for any Avionics System we develop (and so they have requirements about them) but they are not uml::Actors for any of them (there is no use case where they have some interaction with the system). · Flights parameters are provided by some Avionics Computers are also used by systems from .the Open World. domain (cabin) to display flight information to the passengers. Thus some avionics computer systems are uml::Actors for the open world.s systems but they are not stakeholder of them they get no added value from them and has no requirement about them because it has no need of them. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: jeudi 6 juin 2013 16:11 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 While there are always special cases, use case theory, of which there are many books on this, consistency state that the use case is a set of purposes for which an actor wishes the system to perform or help him with. Detaching use cases from the needs/wishes/goals of the actors will have significant methodological consequences. Now, it.s possible that some particular methodology will occasionally use the use case form to capture behaviors that don.t really have goal-oriented actors (e.g., environment, time, maintenance), though it.s usually possible to figure out who the real actor is in such cases. I would not recommend a change here. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 10:03 AM To: Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] ballot 6: issue 18726 Steve, Ok to create a new issue for this. Quoted from §18.1.3, p686: .An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.. There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about .actor.s needs/requirements. in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment. Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 6 juin 2013 15:35 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 Yves This particular wording - .de.ned according to the needs of Actors. - comes from before and has nothing to do with the topic of the issue. The resolution to 18726 does not introduce or change this phrase; its appearance in the resolution text is purely ancillary and contextual, and it could be replaced by .... withouut affecting the resolution. In any case I disagree with you: .according to the roles of Actors. makes no sense to me, whereas the current text does make some sense. If you feel this wording needs to be changed, that would be a separate issue, and I think you would have to explain why Actors do not have needs, given that UseCases are all about specifying requirements. .Needs. and .requirements. are pretty much synonyms, and I think this phrase explains that the overall requirements are partitioned according to the requirements (needs) that relate to particular Actors. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 06 June 2013 13:48 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot 6: issue 18726 About UseCase description. The new text proposed for §18.1.1 includes the following sentence: .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the needs of Actors.. Actors not always have particular .needs. regarding the subject of the UseCase. I suggest replacing this sentence by .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the roles of Actors.. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measur From: "Chonoles, Michael J" To: "pete.rivett@adaptive.com" , "Manfred R. Koethe" , "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Topic: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Index: AQHOZeN9CT9hefTCykCKrnoad5USCJkvCCpg Date: Mon, 10 Jun 2013 14:53:25 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.186.156.82] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-06-10_03:2013-06-10,2013-06-10,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org The other approach would be to remove some of the limitations on the actor, the only one that is truly required is the actor not be part of the subject. Yes, a realization would be ok, however, following Occam.s Razor, we shouldn.t be required to make up two entities when one would do. Michael From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Monday, June 10, 2013 10:05 AM To: Manfred R. Koethe; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) .Outside the system. is problematic when the overall (set of) models is a system composed of many (sub-)systems where what is external to one is internal to another. We should have something to state how, for example, a Realization could be used to link a Class within an external modeled system to an external Actor. Probably a separate issue though . do we have one covering this?< Also the new text still AFAIK retains the following which does not fit with your point that a system may not know about the actor (in which case it cannot be said to collaborate with it) A UseCase is a kind of BehavioredClassifier that represents a declaration of a set of offered Behaviors. Each UseCase specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more Actors. Pete From: Manfred R. Koethe [mailto:koethe@88solutions.com] Sent: Sunday, June 09, 2013 9:36 AM To: uml25-ftf@omg.org Subject: Re: [UML 2.5 FTF] issue 18760 (was 18726) Sorry coming late to the discussion. I think the previous discussion tried to interpret too much power and functionality into the Actor. By definition an Actor is just an entity that is *outside* the system and its only means of interacting with the system is by exchanging information along the System-boundary-crossing Association between Actor and UseCase. This information flow *may* influence the behavior represented by the UseCase, and thus the behavior of the System. But the "interaction" might also be totally observatory where the Actor is receiving information pushed out from the UseCase. In that case the System might even be totally unaware of the Actor's existence. I think we should just state this fact of an Actor being an outside entity interacting with the System by means of information flowing along an Association between Actor and one or more UseCases, and abstain from any further interpretation into that like needs, stake holders, roles, etc. It might be worth to mention that this kind of interaction aids the discovery of all required interfaces to be provided by the System. Kind regards, Manfred On Jun 7, 2013, at 11:32 , "BERNARD, Yves" wrote: Michael, So, according to your last sentence: .There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. and since the actors are those (external) entities participating to use cases, you finally agree that the .needs. according to which these use cases are defined cannot be restricted to those of their actors and thus that §18.1.1 should be modified, don.t you? Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: vendredi 7 juin 2013 16:32 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) In almost all cases where you have an actor who is not a stakeholder, you either have 1) An intermediary, who transfers information to/from a stakeholder. For example, we don.t usually include terminals and keyboards as actors 2) A worker, who is really a design element, and are part of the entire system. For example, data-entry people are replaceable, in theory, by robots or other automation, and have no independent goals. They ultimately are a variety of intermediary above. We can often completely design or eliminate their system interaction if we wish. 3) External systems, whose owners and stakeholders, are the represented by the external system actor. 4) Passive external systems, databases, people, etc. They are queried by the subject systems, but don.t have any independent goals. These are sometimes called secondary actors, as they are usally contacted by the system to when a use case is triggered by a primary actor who actually has a goal. 5) Environmental triggers, where the setters of the threshold for the trigger is the setter. For example, an air condition turning on based on rising temperature or an alarm clock ringing because a time has been reached, while might be diagrammed as environment or time as the actor, but they are proxies for the actor who sets the temperature / time for the trigger . who reeally has the goals So, there are some actors or roles that may be modeled as actors that may not have direct goals, But for each use case (perhaps with some very rare exceptions) have some primary actor who either has the goals, or acts a proxy for the actor/stakeholder with the goals. There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 12:24 PM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Michael, To me an entity who/which has needs/whishes/requirements/goals is a stakeholder. A stakeholder can be an uml::Actor of the system of interest or not. It is if it has some interactions with the system (in the frame of a particular use case) and it is not otherwise. I agree that in most cases entities which are stakeholders are uml::Actors as well but nothing implies this since each concept has its own definition and they are unrelated. Examples: · Airworthiness authorities are stakeholders for any Avionics System we develop (and so they have requirements about them) but they are not uml::Actors for any of them (there is no use case where they have some interaction with the system). · Flights parameters are provided by some Avionics Computers are also used by systems from .the Open World. domain (cabin) to display flight information to the passengers. Thus some avionics computer systems are uml::Actors for the open world.s systems but they are not stakeholder of them they get no added value from them and has no requirement about them because it has no need of them. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: jeudi 6 juin 2013 16:11 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 While there are always special cases, use case theory, of which there are many books on this, consistency state that the use case is a set of purposes for which an actor wishes the system to perform or help him with. Detaching use cases from the needs/wishes/goals of the actors will have significant methodological consequences. Now, it.s possible that some particular methodology will occasionally use the use case form to capture behaviors that don.t really have goal-oriented actors (e.g., environment, time, maintenance), though it.s usually possible to figure out who the real actor is in such cases. I would not recommend a change here. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 10:03 AM To: Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] ballot 6: issue 18726 Steve, Ok to create a new issue for this. Quoted from §18.1.3, p686: .An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.. There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about .actor.s needs/requirements. in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment. Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 6 juin 2013 15:35 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 Yves This particular wording - .de.ned according to the needs of Actors. - comes from before and has nothing to do with the topic of the issue. The resolution to 18726 does not introduce or change this phrase; its appearance in the resolution text is purely ancillary and contextual, and it could be replaced by .... without affecting the resolution. In any case I disagree with you: .according to the roles of Actors. makes no sense to me, whereas the current text does make some sense. If you feel this wording needs to be changed, that would be a separate issue, and I think you would have to explain why Actors do not have needs, given that UseCases are all about specifying requirements. .Needs. and .requirements. are pretty much synonyms, and I think this phrase explains that the overall requirements are partitioned according to the requirements (needs) that relate to particular Actors. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 06 June 2013 13:48 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot 6: issue 18726 About UseCase description. The new text proposed for §18.1.1 includes the following sentence: .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the needs of Actors.. Actors not always have particular .needs. regarding the subject of the UseCase. I suggest replacing this sentence by .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the roles of Actors.. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- Subject: Re: [UML 2.5 FTF] issue 18760 (was 18726) From: "Manfred R. Koethe" Date: Mon, 10 Jun 2013 21:09:42 -0400 Cc: To: Pete Rivett X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:ipf33BI4AyVeYRbz4n2eJralt/6QSJ/ubDvDf9LjLxx l1Y/bFrJr+Y0F1WlYM2G3bhpLw+gu8WzpD1BSEacIXbaLThOpZ 3IqLMti7C4siYJ0uIImJZg4derzOLw/IeHJ1dsfcBKjmhF+TZC R119I2bsKc6bfsiXK8EopxixHCp+h2SXOxyk0h9Pv3qip4cg0s /dlZ2N3IUrwHjsJm2+jURInk+vAJ68eV0TNyz9cxUgaoX3mxxr yvEyz6lTpFiKXk4OuNRRj9m4f8+6BQMiKMMKz9PtCAQxf2Tys+ ERC2Nk3/tjX3jXcY3jl1HDN0BXC28da+wXD9++8va3DG8zB6RT pcGXOTFADRjawPtgcyhV03mBJYU/N8+sPCkqApq3NL4Rb07FDE XyS9LHKALKB0Q== X-Virus-Scanned: amavisd-new at omg.org Pete, âOutside the systemâ is problematic when the overall (set of) models is a system composed of many (sub-)systems where what is external to one is internal to another. [MRK] "Outside the System" was with respect to the System Box drawn around a set of UseCases. But besides that, I share your point. Also the new text still AFAIK retains the following which does not fit with your point that a system may not know about the actor (in which case it cannot be said to collaborate with it) A UseCase is a kind of BehavioredClassifier that represents a declaration of a set of offered Behaviors. Each UseCase specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more Actors. [MRK] Hm, I was probably not precise enough. When the UseCase is for example an event source, then the Association between UseCase and Actor defines only the interface. The Actor, as event subscriber, has most likely no effect on the UseCase. But anyways, I used this argument against the believe that an Actor has always influence on the UseCase, or even is (always ?) a stake holder. In my opinion it is just an external element. Kind regards, Manfred Pete From: Manfred R. Koethe [mailto:koethe@88solutions.com] Sent: Sunday, June 09, 2013 9:36 AM To: uml25-ftf@omg.org Subject: Re: [UML 2.5 FTF] issue 18760 (was 18726) Sorry coming late to the discussion. I think the previous discussion tried to interpret too much power and functionality into the Actor. By definition an Actor is just an entity that is *outside* the system and its only means of interacting with the system is by exchanging information along the System-boundary-crossing Association between Actor and UseCase. This information flow *may* influence the behavior represented by the UseCase, and thus the behavior of the System. But the "interaction" might also be totally observatory where the Actor is receiving information pushed out from the UseCase. In that case the System might even be totally unaware of the Actor's existence. I think we should just state this fact of an Actor being an outside entity interacting with the System by means of information flowing along an Association between Actor and one or more UseCases, and abstain from any further interpretation into that like needs, stake holders, roles, etc. It might be worth to mention that this kind of interaction aids the discovery of all required interfaces to be provided by the System. Kind regards, Manfred On Jun 7, 2013, at 11:32 , "BERNARD, Yves" wrote: Michael, So, according to your last sentence: âThere is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use caseâ and since the actors are those (external) entities participating to use cases, you finally agree that the âneedsâ according to which these use cases are defined cannot be restricted to those of their actors and thus that §18.1.1 should be modified, donât you? Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: vendredi 7 juin 2013 16:32 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) In almost all cases where you have an actor who is not a stakeholder, you either have 1) An intermediary, who transfers information to/from a stakeholder. For example, we donât usually include terminals and keyboards as actors 2) A worker, who is really a design element, and are part of the entire system. For example, data-entry people are replaceable, in theory, by robots or other automation, and have no independent goals. They ultimately are a variety of intermediary above. We can often completely design or eliminate their system interaction if we wish. 3) External systems, whose owners and stakeholders, are the represented by the external system actor. 4) Passive external systems, databases, people, etc. They are queried by the subject systems, but donât have any independent goals. These are sometimes called secondary actors, as they are usally contacted by the system to when a use case is triggered by a primary actor who actually has a goal. 5) Environmental triggers, where the setters of the threshold for the trigger is the setter. For example, an air condition turning on based on rising temperature or an alarm clock ringing because a time has been reached, while might be diagrammed as environment or time as the actor, but they are proxies for the actor who sets the temperature / time for the trigger . who really has the goals So, there are some actors or roles that may be modeled as actors that may not have direct goals, But for each use case (perhaps with some very rare exceptions) have some primary actor who either has the goals, or acts a proxy for the actor/stakeholder with the goals. There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 12:24 PM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Michael, To me an entity who/which has needs/whishes/requirements/goals is a stakeholder. A stakeholder can be an uml::Actor of the system of interest or not. It is if it has some interactions with the system (in the frame of a particular use case) and it is not otherwise. I agree that in most cases entities which are stakeholders are uml::Actors as well but nothing implies this since each concept has its own definition and they are unrelated. Examples: · Airworthiness authorities are stakeholders for any Avionics System we develop (and so they have requirements about them) but they are not uml::Actors for any of them (there is no use case where they have some interaction with the system). · Flights parameters are provided by some Avionics Computers are also used by systems from âthe Open Worldâ domain (cabin) to display flight information to the passengers. Thus some avionics computer systems are uml::Actors for the open worldâs systems but they are not stakeholder of them they get no added value from them and has no requirement about them because it has no need of them. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: jeudi 6 juin 2013 16:11 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 While there are always special cases, use case theory, of which there are many books on this, consistency state that the use case is a set of purposes for which an actor wishes the system to perform or help him with. Detaching use cases from the needs/wishes/goals of the actors will have significant methodological consequences. Now, itâs possible that some particular methodology will occasionally use the use case form to capture behaviors that donât really have goal-oriented actors (e.g., environment, time, maintenance), though itâs usually possible to figure out who the real actor is in such cases. I would not recommend a change here. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 10:03 AM To: Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] ballot 6: issue 18726 Steve, Ok to create a new issue for this. Quoted from §18.1.3, p686: âAn Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.â There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about âactorâs needs/requirementsâ in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment. Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 6 juin 2013 15:35 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 Yves This particular wording - âdeï¬ned according to the needs of Actorsâ - comes from before and has nothing to do with the topic of the issue. The resolution to 18726 does not introduce or change this phrase; its appearance in the resolution text is purely ancillary and contextual, and it could be replaced by â..â without affecting the resolution. In any case I disagree with you: âaccording to the roles of Actorsâ makes no sense to me, whereas the current text does make some sense. If you feel this wording needs to be changed, that would be a separate issue, and I think you would have to explain why Actors do not have needs, given that UseCases are all about specifying requirements. âNeedsâ and ârequirementsâ are pretty much synonyms, and I think this phrase explains that the overall requirements are partitioned according to the requirements (needs) that relate to particular Actors. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 06 June 2013 13:48 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot 6: issue 18726 About UseCase description. The new text proposed for §18.1.1 includes the following sentence: âThe required behavior of the subject is speciï¬ed by one or more UseCases, which are deï¬ned according to the needs of Actors.â Actors not always have particular âneedsâ regarding the subject of the UseCase. I suggest replacing this sentence by âThe required behavior of the subject is speciï¬ed by one or more UseCases, which are deï¬ned according to the roles of Actors.â Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- From: "BERNARD, Yves" To: "Chonoles, Michael J" , Steve Cook , "uml25-ftf@omg.org" Date: Tue, 11 Jun 2013 11:28:29 +0200 Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Topic: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Index: AQHOYtJWArTAdJydlEu6DnprzJF8TJkqS9YAgAAU0gCABKvMgIABMKOQ Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Sorry but your reasoning appears too much convoluted to me. I think it is worth rewording this sentence because what it actually says is not what your .leeway. interpretation does. I cannot see what could mean .needs of Actors. if those actors are not the source of these needs. In the common sense .source. and .owner. are the same. I believe that something like: .The required behavior of the subject is speci.ed by one or more UseCases, in terms of collaboration with Actors. would be more convenient. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: lundi 10 juin 2013 16:50 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Well, I.m not recommending that the sentence be changed. There is some leeway interpretation of the sentence: .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the needs of Actors.. The Use Cases are correctly defined according to the needs of Actors. However, the sources of the details of the requirements could be other stakeholders. Still they should be all defined according to the needs of the primary Actors, e.g., using the actor terminology. michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, June 07, 2013 11:32 AM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Michael, So, according to your last sentence: .There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. and since the actors are those (external) entities participating to use cases, you finally agree that the .needs. according to which these use cases are defined cannot be restricted to those of their actors and thus that §18.1.1 should be modified, don.t you? Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: vendredi 7 juin 2013 16:32 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) In almost all cases where you have an actor who is not a stakeholder, you either have 1) An intermediary, who transfers information to/from a stakeholder. For example, we don.t usually include terminals and keyboards as actors 2) A worker, who is really a design element, and are part of the entire system. For example, data-entry people are replaceable, in theory, by robots or other automation, and have no independent goals. They ultimately are a variety of intermediary above. We can often completely design or eliminate their system interaction if we wish. 3) External systems, whose owners and stakeholders, are the represented by the external system actor. 4) Passive external systems, databases, people, etc. They are queried by the subject systems, but don.t have any independent goals. These are sometimes called secondary actors, as they are usally contacted by the system to when a use case is triggered by a primary actor who actually has a goal. 5) Environmental triggers, where the setters of the threshold for the trigger is the setter. For example, an air condition turning on based on rising temperature or an alarm clock ringing because a time has been reached, while might be diagrammed as environment or time as the actor, but they are proxies for the actor who sets the temperature / time for the trigger . who really has the goals< So, there are some actors or roles that may be modeled as actors that may not have direct goals, But for each use case (perhaps with some very rare exceptions) have some primary actor who either has the goals, or acts a proxy for the actor/stakeholder with the goals. There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 12:24 PM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Michael, To me an entity who/which has needs/whishes/requirements/goals is a stakeholder. A stakeholder can be an uml::Actor of the system of interest or not. It is if it has some interactions with the system (in the frame of a particular use case) and it is not otherwise. I agree that in most cases entities which are stakeholders are uml::Actors as well but nothing implies this since each concept has its own definition and they are unrelated. Examples: · Airworthiness authorities are stakeholders for any Avionics System we develop (and so they have requirements about them) but they are not uml::Actors for any of them (there is no use case where they have some interaction with the system). · Flights parameters are provided by some Avionics Computers are also used by systems from .the Open World. domain (cabin) to display flight information to the passengers. Thus some avionics computer systems are uml::Actors for the open world.s systems but they are not stakeholder of them they get no added value from them and has no requirement about them because it has no need of them. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: jeudi 6 juin 2013 16:11 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 While there are always special cases, use case theory, of which there are many books on this, consistency state that the use case is a set of purposes for which an actor wishes the system to perform or help him with. Detaching use cases from the needs/wishes/goals of the actors will have significant methodological consequences. Now, it.s possible that some particular methodology will occasionally use the use case form to capture behaviors that don.t really have goal-oriented actors (e.g., environment, time, maintenance), though it.s usually possible to figure out who the real actor is in such cases. I would not recommend a change here. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 10:03 AM To: Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] ballot 6: issue 18726 Steve, Ok to create a new issue for this. Quoted from §18.1.3, p686: .An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.. There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about .actor.s needs/requirements. in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment. Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 6 juin 2013 15:35 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 Yves This particular wording - .de.ned according to the needs of Actors. - comes from before and has nothing to do with the topic of the issue. The resolution to 18726 does not introduce or change this phrase; its appearance in the resolution text is purely ancillary and contextual, and it could be replaced by .... wiithout affecting the resolution. In any case I disagree with you: .according to the roles of Actors. makes no sense to me, whereas the current text does make some sense. If you feel this wording needs to be changed, that would be a separate issue, and I think you would have to explain why Actors do not have needs, given that UseCases are all about specifying requirements. .Needs. and .requirements. are pretty much synonyms, and I think this phrase explains that the overall requirements are partitioned according to the requirements (needs) that relate to particular Actors. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 06 June 2013 13:48 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot 6: issue 18726 About UseCase description. The new text proposed for §18.1.1 includes the following sentence: .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the needs of Actors.. Actors not always have particular .needs. regarding the subject of the UseCase. I suggest replacing this sentence by .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the roles of Actors.. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Chonoles, Michael J" To: "BERNARD, Yves" CC: Steve Cook , "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Topic: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Index: AQHOYtJWArTAdJydlEu6DnprzJF8TJkqS9YAgAAU0gCABKvMgIABMKOQgABctCA= Date: Tue, 11 Jun 2013 14:29:50 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.186.156.82] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-06-11_06:2013-06-11,2013-06-11,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org Well, that.s not quite true either. How about 1) Drop the sentence entirely, or 2) .Some of the required behavior of the subject is specified by one or more UseCases. Either avoids getting into methodology, and possibly contradicting myriad of books and courses on the subject. It also avoids the appearance that the only behavior a subject can have must be specified in UseCases. From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, June 11, 2013 5:28 AM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Sorry but your reasoning appears too much convoluted to me. I think it is worth rewording this sentence because what it actually says is not what your .leeway. interpretation does. I cannot see what could mean .needs of Actors. if those actors are not the source of these needs. In the common sense .source. and .owner. are the same. I believe that something like: .The required behavior of the subject is speci.ed by one or more UseCases, in terms of collaboration with Actors. would be more convenient. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: lundi 10 juin 2013 16:50 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Well, I.m not recommending that the sentence be changed. There is some leeway interpretation of the sentence: .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the needs of Actors.. The Use Cases are correctly defined according to the needs of Actors. However, the sources of the details of the requirements could be other stakeholders. Still they should be all defined according to the needs of the primary Actors, e.g., using the actor terminology. michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, June 07, 2013 11:32 AM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Michael, So, according to your last sentence: .There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. and since the actors are those (external) entities participating to use cases, you finally agree that the .needs. according to which these use cases are defined cannot be restricted to those of their actors and thus that §18.1.1 should be modified, don.t you? Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: vendredi 7 juin 2013 16:32 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) In almost all cases where you have an actor who is not a stakeholder, you either have 1) An intermediary, who transfers information to/from a stakeholder. For example, we don.t usually include terminals and keyboards as actors 2) A worker, who is really a design element, and are part of the entire system. For example, data-entry people are replaceable, in theory, by robots or other automation, and have no independent goals. They ultimately are a variety of intermediary above. We can often completely design or eliminate their system interaction if we wish. 3) External systems, whose owners and stakeholders, are the represented by the external system actor. 4) Passive external systems, databases, people, etc. They are queried by the subject systems, but don.t have any independent goals. These are sometimes called secondary actors, as they are usally contacted by the system to when a use case is triggered by a primary actor who actually has a goal. 5) Environmental triggers, where the setters of the threshold for the trigger is the setter. For example, an air condition turning on based on rising temperature or an alarm clock ringing because a time has been reached, while might be diagrammed as environment or time as the actor, but they are proxies for the actor who sets the temperature / time for the trigger . who really haas the goals So, there are some actors or roles that may be modeled as actors that may not have direct goals, But for each use case (perhaps with some very rare exceptions) have some primary actor who either has the goals, or acts a proxy for the actor/stakeholder with the goals. There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 12:24 PM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Michael, To me an entity who/which has needs/whishes/requirements/goals is a stakeholder. A stakeholder can be an uml::Actor of the system of interest or not. It is if it has some interactions with the system (in the frame of a particular use case) and it is not otherwise. I agree that in most cases entities which are stakeholders are uml::Actors as well but nothing implies this since each concept has its own definition and they are unrelated. Examples: · Airworthiness authorities are stakeholders for any Avionics System we develop (and so they have requirements about them) but they are not uml::Actors for any of them (there is no use case where they have some interaction with the system). · Flights parameters are provided by some Avionics Computers are also used by systems from .the Open World. domain (cabin) to display flight information to the passengers. Thus some avionics computer systems are uml::Actors for the open world.s systems but they are not stakeholder of them they get no added value from them and has no requirement about them because it has no need of them. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: jeudi 6 juin 2013 16:11 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 While there are always special cases, use case theory, of which there are many books on this, consistency state that the use case is a set of purposes for which an actor wishes the system to perform or help him with. Detaching use cases from the needs/wishes/goals of the actors will have significant methodological consequences. Now, it.s possible that some particular methodology will occasionally use the use case form to capture behaviors that don.t really have goal-oriented actors (e.g., environment, time, maintenance), though it.s usually possible to figure out who the real actor is in such cases. I would not recommend a change here. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 10:03 AM To: Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] ballot 6: issue 18726 Steve, Ok to create a new issue for this. Quoted from §18.1.3, p686: .An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.. There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about .actor.s needs/requirements. in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment. Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 6 juin 2013 15:35 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 Yves This particular wording - .de.ned according to the needs of Actors. - comes from before and has nothing to do with the topic of the issue. The resolution to 18726 does not introduce or change this phrase; its appearance in the resolution text is purely ancillary and contextual, and it could be replaced by .... without affecting the resolution.< In any case I disagree with you: .according to the roles of Actors. makes no sense to me, whereas the current text does make some sense. If you feel this wording needs to be changed, that would be a separate issue, and I think you would have to explain why Actors do not have needs, given that UseCases are all about specifying requirements. .Needs. and .requirements. are pretty much synonyms, and I think this phrase explains that the overall requirements are partitioned according to the requirements (needs) that relate to particular Actors. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 06 June 2013 13:48 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot 6: issue 18726 About UseCase description. The new text proposed for §18.1.1 includes the following sentence: .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the needs of Actors.. Actors not always have particular .needs. regarding the subject of the UseCase. I suggest replacing this sentence by .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the roles of Actors.. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free From: Steve Cook To: "Chonoles, Michael J" , "BERNARD, Yves" CC: "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Topic: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Index: AQHOYtMX5qyCfqh5oEajs80i+wgRQpkqS9YAgAAU0gCABKvMgIABMKOQgABdhQCAAAL3AA== Date: Tue, 11 Jun 2013 14:42:56 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.101] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(31014003)(189002)(365934002)(5403001)(199002)(377454002)(74366001)(54356001)(77982001)(512874002)(76482001)(4396001)(31966008)(63696002)(79102001)(80022001)(44976003)(59766001)(15202345002)(56816003)(53806001)(16406001)(54316002)(6806003)(65816001)(77096001)(55846006)(47976001)(56776001)(74662001)(33656001)(81542001)(16236675002)(76796001)(51856001)(46102001)(74502001)(49866001)(20776003)(74706001)(76786001)(71186001)(50986001)(47736001)(74876001)(47446002)(69226001)(81342001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB013;H:TK5EX14HUBC104.redmond.corp.microsoft.com;CLIP:131.107.125.37;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 087474FBFA X-Virus-Scanned: amavisd-new at omg.org I believe this issue, on which there has already been a disproportionate amount of energy expended, may be resolved by deleting the phrase .which are defined according to the needs of Actors.. -- Steve From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: 11 June 2013 15:30 To: BERNARD, Yves Cc: Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Well, that.s not quite true either. How about 1) Drop the sentence entirely, or 2) .Some of the required behavior of the subject is specified by one or more UseCases. Either avoids getting into methodology, and possibly contradicting myriad of books and courses on the subject. It also avoids the appearance that the only behavior a subject can have must be specified in UseCases. From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, June 11, 2013 5:28 AM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Sorry but your reasoning appears too much convoluted to me. I think it is worth rewording this sentence because what it actually says is not what your .leeway. interpretation does. I cannot see what could mean .needs of Actors. if those actors are not the source of these needs. In the common sense .source. and .owner. are the same. I believe that something like: .The required behavior of the subject is speci.ed by one or more UseCases, in terms of collaboration with Actors. would be more convenient. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: lundi 10 juin 2013 16:50 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Well, I.m not recommending that the sentence be changed. There is some leeway interpretation of the sentence: .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the needs of Actors.. The Use Cases are correctly defined according to the needs of Actors. However, the sources of the details of the requirements could be other stakeholders. Still they should be all defined according to the needs of the primary Actors, e.g., using the actor terminology. michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, June 07, 2013 11:32 AM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Michael, So, according to your last sentence: .There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. and since the actors are those (external) entities participating to use cases, you finally agree that the .needs. according to which these use cases are defined cannot be restricted to those of their actors and thus that §18.1.1 should be modified, don.t you? Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: vendredi 7 juin 2013 16:32 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) In almost all cases where you have an actor who is not a stakeholder, you either have 1) An intermediary, who transfers information to/from a stakeholder. For example, we don.t usually include terminals and keyboards as actors 2) A worker, who is really a design element, and are part of the entire system. For example, data-entry people are replaceable, in theory, by robots or other automation, and have no independent goals. They ultimately are a variety of intermediary above. We can often completely design or eliminate their system interaction if we wish. 3) External systems, whose owners and stakeholders, are the represented by the external system actor. 4) Passive external systems, databases, people, etc. They are queried by the subject systems, but don.t have any independent goals. These are sometimes called secondary actors, as they are usally contacted by the system to when a use case is triggered by a primary actor who actually has a goal. 5) Environmental triggers, where the setters of the threshold for the trigger is the setter. For example, an air condition turning on based on rising temperature or an alarm clock ringing because a time has been reached, while might be diagrammed as environment or time as the actor, but they are proxies for the actor who sets the temperature / time for the trigger . who really has the goals So, there are some actors or roles that may be modeled as actors that may not have direct goals, But for each use case (perhaps with some very rare exceptions) have some primary actor who either has the goals, or acts a proxy for the actor/stakeholder with the goals. There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 12:24 PM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Michael, To me an entity who/which has needs/whishes/requirements/goals is a stakeholder. A stakeholder can be an uml::Actor of the system of interest or not. It is if it has some interactions with the system (in the frame of a particular use case) and it is not otherwise. I agree that in most cases entities which are stakeholders are uml::Actors as well but nothing implies this since each concept has its own definition and they are unrelated. Examples: · Airworthiness authorities are stakeholders for any Avionics System we develop (and so they have requirements about them) but they are not uml::Actors for any of them (there is no use case where they have some interaction with the system). · Flights parameters are provided by some Avionics Computers are also used by systems from .the Open World. domain (cabin) to display flight information to the passengers. Thus some avionics computer systems are uml::Actors for the open world.s systems but they are not stakeholder of them they get no added value from them and has no requirement about them because it has no need of them. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: jeudi 6 juin 2013 16:11 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 While there are always special cases, use case theory, of which there are many books on this, consistency state that the use case is a set of purposes for which an actor wishes the system to perform or help him with. Detaching use cases from the needs/wishes/goals of the actors will have significant methodological consequences. Now, it.s possible that some particular methodology will occasionally use the use case form to capture behaviors that don.t really have goal-oriented actors (e.g., environment, time, maintenance), though it.s usually possible to figure out who the real actor is in such cases. I would not recommend a change here. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 10:03 AM To: Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] ballot 6: issue 18726 Steve, Ok to create a new issue for this. Quoted from §18.1.3, p686: .An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.. There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about .actor.s needs/requirements. in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment. Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 6 juin 2013 15:35 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 Yves This particular wording - .de.ned according to the needs of Actors. - comes from before and has nothing to do with the topic of the issue. The resolution to 18726 does not introduce or change this phrase; its appearance in the resolution text is purely ancillary and contextual, and it could be replaced by .... without affecting the resolution. In any case I disagree with you: .according to the roles of Actors. makes no sense to me, whereas the current text does make some sense. If you feel this wording needs to be changed, that would be a separate issue, and I think you would have to explain why Actors do not have needs, given that UseCases are all about specifying requirements. .Needs. and .requirements. are pretty much synonyms, and I think this phrase explains that the overall requirements are partitioned according to the requirements (needs) that relate to particular Actors. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 06 June 2013 13:48 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot 6: issue 18726 About UseCase description. The new text proposed for §18.1.1 includes the following sentence: .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the needs of Actors.. Actors not always have particular .needs. regarding the subject of the UseCase. I suggest replacing this sentence by .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the roles of Actors.. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "BERNARD, Yves" To: "Chonoles, Michael J" CC: Steve Cook , "uml25-ftf@omg.org" Date: Tue, 11 Jun 2013 17:32:22 +0200 Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Topic: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Index: AQHOYtJWArTAdJydlEu6DnprzJF8TJkqS9YAgAAU0gCABKvMgIABMKOQgABctCCAAAv+cA== Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Dropping the entire sentence would be a rather radical solution but it.s acceptable anyway. On the other hand the sentence I proposed is fully consistent with the semantics section. Cf. §18.1.3 second paragraph, second sentence: .Each UseCase specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more Actors.. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: mardi 11 juin 2013 16:30 To: BERNARD, Yves Cc: Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Well, that.s not quite true either. How about 1) Drop the sentence entirely, or 2) .Some of the required behavior of the subject is specified by one or more UseCases. Either avoids getting into methodology, and possibly contradicting myriad of books and courses on the subject. It also avoids the appearance that the only behavior a subject can have must be specified in UseCases. From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, June 11, 2013 5:28 AM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Sorry but your reasoning appears too much convoluted to me. I think it is worth rewording this sentence because what it actually says is not what your .leeway. interpretation does. I cannot see what could mean .needs of Actors. if those actors are not the source of these needs. In the common sense .source. and .owner. are the same. I believe that something like: .The required behavior of the subject is speci.ed by one or more UseCases, in terms of collaboration with Actors. would be more convenient. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: lundi 10 juin 2013 16:50 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Well, I.m not recommending that the sentence be changed. There is some leeway interpretation of the sentence: .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the needs of Actors.. The Use Cases are correctly defined according to the needs of Actors. However, the sources of the details of the requirements could be other stakeholders. Still they should be all defined according to the needs of the primary Actors, e.g., using the actor terminology. michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, June 07, 2013 11:32 AM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Michael, So, according to your last sentence: .There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. and since the actors are those (external) entities participating to use cases, you finally agree that the .needs. according to which these use cases are defined cannot be restricted to those of their actors and thus that §18.1.1 should be modified, don.t you? Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: vendredi 7 juin 2013 16:32 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) In almost all cases where you have an actor who is not a stakeholder, you either have 1) An intermediary, who transfers information to/from a stakeholder. For example, we don.t usually include terminals and keyboards as actors 2) A worker, who is really a design element, and are part of the entire system. For example, data-entry people are replaceable, in theory, by robots or other automation, and have no independent goals. They ultimately are a variety of intermediary above. We can often completely design or eliminate their system interaction if we wish. 3) External systems, whose owners and stakeholders, are the represented by the external system actor. 4) Passive external systems, databases, people, etc. They are queried by the subject systems, but don.t have any independent goals. These are sometimes called secondary actors, as they are usally contacted by the system to when a use case is triggered by a primary actor who actually has a goal. 5) Environmental triggers, where the setters of the threshold for the trigger is the setter. For example, an air condition turning on based on rising temperature or an alarm clock ringing because a time has been reached, while might be diagrammed as environment or time as the actor, but they are proxies for the actor who sets the temperature / time for the trigger . who really has the goals So, there are some actors or roles that may be modeled as actors that may not have direct goals, But for each use case (perhaps with some very rare exceptions) have some primary actor who either has the goals, or acts a proxy for the actor/stakeholder with the goals. There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 12:24 PM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Michael, To me an entity who/which has needs/whishes/requirements/goals is a stakeholder. A stakeholder can be an uml::Actor of the system of interest or not. It is if it has some interactions with the system (in the frame of a particular use case) and it is not otherwise. I agree that in most cases entities which are stakeholders are uml::Actors as well but nothing implies this since each concept has its own definition and they are unrelated. Examples: · Airworthiness authorities are stakeholders for any Avionics System we develop (and so they have requirements about them) but they are not uml::Actors for any of them (there is no use case where they have some interaction with the system). · Flights parameters are provided by some Avionics Computers are also used by systems from .the Open World. domain (cabin) to display flight information to the passengers. Thus some avionics computer systems are uml::Actors for the open world.s systems but they are not stakeholder of them they get no added value from them and has no requirement about them because it has no need of them. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: jeudi 6 juin 2013 16:11 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 While there are always special cases, use case theory, of which there are many books on this, consistency state that the use case is a set of purposes for which an actor wishes the system to perform or help him with. Detaching use cases from the needs/wishes/goals of the actors will have significant methodological consequences. Now, it.s possible that some particular methodology will occasionally use the use case form to capture behaviors that don.t really have goal-oriented actors (e.g., environment, time, maintenance), though it.s usually possible to figure out who the real actor is in such cases. I would not recommend a change here. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 10:03 AM To: Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] ballot 6: issue 18726 Steve, Ok to create a new issue for this. Quoted from §18.1.3, p686: .An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.. There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about .actor.s needs/requirements. in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment. Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 6 juin 2013 15:35 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 Yves This particular wording - .de.ned according to the needs of Actors. - comes from before and has nothing to do with the topic of the issue. The resolution to 18726 does not introduce or change this phrase; its appearance in the resolution text is purely ancillary and contextual, and it could be replaced by .... without affecting the resolution. In any case I disagree with you: .according to the roles of Actors. makes no sense to me, whereas the current text does make some sense. If you feel this wording needs to be changed, that would be a separate issue, and I think you would have to explain why Actors do not have needs, given that UseCases are all about specifying requirements. .Needs. and .requirements. are pretty much synonyms, and I think this phrase explains that the overall requirements are partitioned according to the requirements (needs) that relate to particular Actors. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 06 June 2013 13:48 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot 6: issue 18726 About UseCase description. The new text proposed for §18.1.1 includes the following sentence: .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the needs of Actors.. Actors not always have particular .needs. regarding the subject of the UseCase. I suggest replacing this sentence by .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the roles of Actors.. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Chonoles, Michael J" To: "BERNARD, Yves" CC: Steve Cook , "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Topic: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Index: AQHOYtJWArTAdJydlEu6DnprzJF8TJkqS9YAgAAU0gCABKvMgIABMKOQgABctCCAAAv+cIAABxTg Date: Tue, 11 Jun 2013 15:37:04 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.186.156.82] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-06-11_06:2013-06-11,2013-06-11,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org Not exactly, the 18.1.3 sentence describes what each UC does. 18.1.1 implies that the entire behavior of a subject is specified in one or more use cases. Let.s drop the entire sentence From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, June 11, 2013 11:32 AM To: Chonoles, Michael J Cc: Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Dropping the entire sentence would be a rather radical solution but it.s acceptable anyway. On the other hand the sentence I proposed is fully consistent with the semantics section. Cf. §18.1.3 second paragraph, second sentence: .Each UseCase specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more Actors.. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: mardi 11 juin 2013 16:30 To: BERNARD, Yves Cc: Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Well, that.s not quite true either. How about 1) Drop the sentence entirely, or 2) .Some of the required behavior of the subject is specified by one or more UseCases. Either avoids getting into methodology, and possibly contradicting myriad of books and courses on the subject. It also avoids the appearance that the only behavior a subject can have must be specified in UseCases. From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, June 11, 2013 5:28 AM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Sorry but your reasoning appears too much convoluted to me. I think it is worth rewording this sentence because what it actually says is not what your .leeway. interpretation does. I cannot see what could mean .needs of Actors. if those actors are not the source of these needs. In the common sense .source. and .owner. are the same. I believe that something like: .The required behavior of the subject is speci.ed by one or more UseCases, in terms of collaboration with Actors. would be more convenient. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: lundi 10 juin 2013 16:50 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Well, I.m not recommending that the sentence be changed. There is some leeway interpretation of the sentence: .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the needs of Actors.. The Use Cases are correctly defined according to the needs of Actors. However, the sources of the details of the requirements could be other stakeholders. Still they should be all defined according to the needs of the primary Actors, e.g., using the actor terminology. michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, June 07, 2013 11:32 AM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Michael, So, according to your last sentence: .There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. and since the actors are those (external) entities participating to use cases, you finally agree that the .needs. according to which these use cases are defined cannot be restricted to those of their actors and thus that §18.1.1 should be modified, don.t you? Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: vendredi 7 juin 2013 16:32 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) In almost all cases where you have an actor who is not a stakeholder, you either have 1) An intermediary, who transfers information to/from a stakeholder. For example, we don.t usually include terminals and keyboards as actors 2) A worker, who is really a design element, and are part of the entire system. For example, data-entry people are replaceable, in theory, by robots or other automation, and have no independent goals. They ultimately are a variety of intermediary above. We can often completely design or eliminate their system interaction if we wish. 3) External systems, whose owners and stakeholders, are the represented by the external system actor. 4) Passive external systems, databases, people, etc. They are queried by the subject systems, but don.t have any independent goals. These are sometimes called secondary actors, as they are usally contacted by the system to when a use case is triggered by a primary actor who actually has a goal. 5) Environmental triggers, where the setters of the threshold for the trigger is the setter. For example, an air condition turning on based on rising temperature or an alarm clock ringing because a time has been reached, while might be diagrammed as environment or time as the actor, but they are proxies for the actor who sets the temperature / time for the trigger . who really has the goals So, there are some actors or roles that may be modeled as actors that may not have direct goals, But for each use case (perhaps with some very rare exceptions) have some primary actor who either has the goals, or acts a proxy for the actor/stakeholder with the goals. There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 12:24 PM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Michael, To me an entity who/which has needs/whishes/requirements/goals is a stakeholder. A stakeholder can be an uml::Actor of the system of interest or not. It is if it has some interactions with the system (in the frame of a particular use case) and it is not otherwise. I agree that in most cases entities which are stakeholders are uml::Actors as well but nothing implies this since each concept has its own definition and they are unrelated. Examples: · Airworthiness authorities are stakeholders for any Avionics System we develop (and so they have requirements about them) but they are not uml::Actors for any of them (there is no use case where they have some interaction with the system). · Flights parameters are provided by some Avionics Computers are also used by systems from .the Open World. domain (cabin) to display flight information to the passengers. Thus some avionics computer systems are uml::Actors for the open world.s systems but they are not stakeholder of them they get no added value from them and has no requirement about them because it has no need of them. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: jeudi 6 juin 2013 16:11 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 While there are always special cases, use case theory, of which there are many books on this, consistency state that the use case is a set of purposes for which an actor wishes the system to perform or help him with. Detaching use cases from the needs/wishes/goals of the actors will have significant methodological consequences. Now, it.s possible that some particular methodology will occasionally use the use case form to capture behaviors that don.t really have goal-oriented actors (e.g., environment, time, maintenance), though it.s usually possible to figure out who the real actor is in such cases. I would not recommend a change here. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 10:03 AM To: Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] ballot 6: issue 18726 Steve, Ok to create a new issue for this. Quoted from §18.1.3, p686: .An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.. There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about .actor.s needs/requirements. in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment. Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 6 juin 2013 15:35 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 Yves This particular wording - .de.ned according to the needs of Actors. - comes from before and has nothing to do with the topic of the issue. The resolution to 18726 does not introduce or change this phrase; its appearance in the resolution text is purely ancillary and contextual, and it could be replaced by .... wiithout affecting the resolution. In any case I disagree with you: .according to the roles of Actors. makes no sense to me, whereas the current text does make some sense. If you feel this wording needs to be changed, that would be a separate issue, and I think you would have to explain why Actors do not have needs, given that UseCases are all about specifying requirements. .Needs. and .requirements. are pretty much synonyms, and I think this phrase explains that the overall requirements are partitioned according to the requirements (needs) that relate to particular Actors. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 06 June 2013 13:48 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot 6: issue 18726 About UseCase description. The new text proposed for §18.1.1 includes the following sentence: .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the needs of Actors.. Actors not always have particular .needs. regarding the subject of the UseCase. I suggest replacing this sentence by .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the roles of Actors.. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "BERNARD, Yves" To: "Chonoles, Michael J" CC: Steve Cook , "uml25-ftf@omg.org" Date: Tue, 11 Jun 2013 18:03:56 +0200 Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Topic: [UML 2.5 FTF] issue 18760 (was 18726) Thread-Index: AQHOYtJWArTAdJydlEu6DnprzJF8TJkqS9YAgAAU0gCABKvMgIABMKOQgABctCCAAAv+cIAABxTggAAH6EA= Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org That.s right. Let.s drop it. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: mardi 11 juin 2013 17:37 To: BERNARD, Yves Cc: Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Not exactly, the 18.1.3 sentence describes what each UC does. 18.1.1 implies that the entire behavior of a subject is specified in one or more use cases. Let.s drop the entire sentence From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, June 11, 2013 11:32 AM To: Chonoles, Michael J Cc: Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Dropping the entire sentence would be a rather radical solution but it.s acceptable anyway. On the other hand the sentence I proposed is fully consistent with the semantics section. Cf. §18.1.3 second paragraph, second sentence: .Each UseCase specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more Actors.. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: mardi 11 juin 2013 16:30 To: BERNARD, Yves Cc: Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Well, that.s not quite true either. How about 1) Drop the sentence entirely, or 2) .Some of the required behavior of the subject is specified by one or more UseCases. Either avoids getting into methodology, and possibly contradicting myriad of books and courses on the subject. It also avoids the appearance that the only behavior a subject can have must be specified in UseCases. From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, June 11, 2013 5:28 AM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Sorry but your reasoning appears too much convoluted to me. I think it is worth rewording this sentence because what it actually says is not what your .leeway. interpretation does. I cannot see what could mean .needs of Actors. if those actors are not the source of these needs. In the common sense .source. and .owner. are the same. I believe that something like: .The required behavior of the subject is speci.ed by one or more UseCases, in terms of collaboration with Actors. would be more convenient. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: lundi 10 juin 2013 16:50 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) Well, I.m not recommending that the sentence be changed. There is some leeway interpretation of the sentence: .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the needs of Actors.. The Use Cases are correctly defined according to the needs of Actors. However, the sources of the details of the requirements could be other stakeholders. Still they should be all defined according to the needs of the primary Actors, e.g., using the actor terminology. michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, June 07, 2013 11:32 AM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Michael, So, according to your last sentence: .There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. and since the actors are those (external) entities participating to use cases, you finally agree that the .needs. according to which these use cases are defined cannot be restricted to those of their actors and thus that §18.1.1 should be modified, don.t you? Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: vendredi 7 juin 2013 16:32 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] issue 18760 (was 18726) In almost all cases where you have an actor who is not a stakeholder, you either have 1) An intermediary, who transfers information to/from a stakeholder. For example, we don.t usually include terminals and keyboards as actors 2) A worker, who is really a design element, and are part of the entire system. For example, data-entry people are replaceable, in theory, by robots or other automation, and have no independent goals. They ultimately are a variety of intermediary above. We can often completely design or eliminate their system interaction if we wish. 3) External systems, whose owners and stakeholders, are the represented by the external system actor. 4) Passive external systems, databases, people, etc. They are queried by the subject systems, but don.t have any independent goals. These are sometimes called secondary actors, as they are usally contacted by the system to when a use case is triggered by a primary actor who actually has a goal. 5) Environmental triggers, where the setters of the threshold for the trigger is the setter. For example, an air condition turning on based on rising temperature or an alarm clock ringing because a time has been reached, while might be diagrammed as environment or time as the actor, but they are proxies for the actor who sets the temperature / time for the trigger . who really has the goals So, there are some actors or roles that may be modeled as actors that may not have direct goals, But for each use case (perhaps with some very rare exceptions) have some primary actor who either has the goals, or acts a proxy for the actor/stakeholder with the goals. There is not, nor has there ever been a claim that all stakeholder/sources of requirements must participate in use case. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 12:24 PM To: Chonoles, Michael J; Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] issue 18760 (was 18726) Michael, To me an entity who/which has needs/whishes/requirements/goals is a stakeholder. A stakeholder can be an uml::Actor of the system of interest or not. It is if it has some interactions with the system (in the frame of a particular use case) and it is not otherwise. I agree that in most cases entities which are stakeholders are uml::Actors as well but nothing implies this since each concept has its own definition and they are unrelated. Examples: · Airworthiness authorities are stakeholders for any Avionics System we develop (and so they have requirements about them) but they are not uml::Actors for any of them (there is no use case where they have some interaction with the system). · Flights parameters are provided by some Avionics Computers are also used by systems from .the Open World. domain (cabin) to display flight information to the passengers. Thus some avionics computer systems are uml::Actors for the open world.s systems but they are not stakeholder of them they get no added value from them and has no requirement about them because it has no need of them. Yves From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: jeudi 6 juin 2013 16:11 To: BERNARD, Yves; Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 While there are always special cases, use case theory, of which there are many books on this, consistency state that the use case is a set of purposes for which an actor wishes the system to perform or help him with. Detaching use cases from the needs/wishes/goals of the actors will have significant methodological consequences. Now, it.s possible that some particular methodology will occasionally use the use case form to capture behaviors that don.t really have goal-oriented actors (e.g., environment, time, maintenance), though it.s usually possible to figure out who the real actor is in such cases. I would not recommend a change here. Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, June 06, 2013 10:03 AM To: Steve Cook; uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] ballot 6: issue 18726 Steve, Ok to create a new issue for this. Quoted from §18.1.3, p686: .An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.. There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about .actor.s needs/requirements. in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment. Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 6 juin 2013 15:35 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot 6: issue 18726 Yves This particular wording - .de.ned according to the needs of Actors. - comes from before and has nothing to do with the topic of the issue. The resolution to 18726 does not introduce or change this phrase; its appearance in the resolution text is purely ancillary and contextual, and it could be replaced by .... without affecting the resolution. In any case I disagree with you: .according to the roles of Actors. makes no sense to me, whereas the current text does make some sense. If you feel this wording needs to be changed, that would be a separate issue, and I think you would have to explain why Actors do not have needs, given that UseCases are all about specifying requirements. .Needs. and .requirements. are pretty much synonyms, and I think this phrase explains that the overall requirements are partitioned according to the requirements (needs) that relate to particular Actors. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 06 June 2013 13:48 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot 6: issue 18726 About UseCase description. The new text proposed for §18.1.1 includes the following sentence: .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the needs of Actors.. Actors not always have particular .needs. regarding the subject of the UseCase. I suggest replacing this sentence by .The required behavior of the subject is speci.ed by one or more UseCases, which are de.ned according to the roles of Actors.. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.