Issue 4619: Using or implementing an interface of a Subsystem (uml2-superstructure-ftf) Source: (, ) Nature: Enhancement Severity: Significant Summary: Problem: The specification part of the UML Subsystem element does not consider the two ways to make use of an interface: 1.) Direct calls. When a client subsystem should invoke operations of the subsystem. 2.) Notifications (extensions). When a client subsystem should receive notifications from the subsystem. Note that the static dependency can be directed the same way in both cases, but a call can either propagate along or against the dependency, depending on what subsystem that is implementing the interface. One-way static dependencies are crucial when a system should be easy to maintain. Therefore, one should distinguish between if a client needs to invoke an operation of the subsystem (implemented by the subsystem) or if the client should implement the interface in order to be notified by the subsystem. If needed, I can provide more information about how this can be seen. Suggestion: I introduced a usage dependency from the subsystem border to the interface in order to show that the subsystem provides and uses an interface which is to be implemented by a client subsystem that is to receive notifications. Background: I have been involved in different projects for Ericsson (the Telecom Business) and for the Swedish Airforce Defence Industry. Basically, the Subsystem modelling element is of great help when modelling large complex systems, such as Telecom systems for Radio Network Management. These systems do not only require robust software architectures, their architectures have to be considered on different architectural levels in order to reduce complexity. Also, the Subsystem modelling element is of great help when delegating and managing responsibility. Resolution: Revised Text: Actions taken: October 15, 2001: received issue March 9, 2005: closed issue Discussion: The new structural modeling capabilities of structured classifiers (which include components and subsystems as specializations), such as delegation connectors, address this issue more effectively. End of Annotations:===== From: webmaster@omg.org Message-Id: <200110141446.f9EEkte23016@emerald.omg.org> Date: 14 Oct 2001 10:49:59 -0400 To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Issue/Bug Report Content-Type: Text/html; charset=windows-1252 X-UIDL: 8Gmd9Ob~e9hG#e9[a/!! Name: Tommy Agren Company: Enea Realtime AB mailFrom: tommy.agren@enea.se Notification: Yes Specification: Using or implementing an interface of a Subsystem Section: Notation Guide 3.14) Model management, Subsystem FormalNumber: AD/01-02-13 Version: UML 1.4 RevisionDate: February 2001 Page: Notation Guide 3.14 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.74 [en] (WinNT; U) Description Dear OMG, My name is Tommy Agren and I am working as an OO Software Architect for a Swedish consultant company. Problem: The specification part of the UML Subsystem element does not consider the two ways to make use of an interface: 1.) Direct calls. When a client subsystem should invoke operations of the subsystem. 2.) Notifications (extensions). When a client subsystem should receive notifications from the subsystem. Note that the static dependency can be directed the same way in both cases, but a call can either propagate along or against the dependency, depending on what subsystem that is implementing the interface. One-way static dependencies are crucial when a system should be easy to maintain. Therefore, one should distinguish between if a client needs to invoke an operation of the subsystem (implemented by the subsystem) or if the client should implement the interface in order to be notified by the subsystem. If needed, I can provide more information about how this can be seen. Suggestion: I introduced a usage dependency from the subsystem border to the interface in order to show that the subsystem provides and uses an interface which is to be implemented by a client subsystem that is to receive notifications. Background: I have been involved in different projects for Ericsson (the Telecom Business) and for the Swedish Airforce Defence Industry. Basically, the Subsystem modelling element is of great help when modelling large complex systems, such as Telecom systems for Radio Network Management. These systems do not only require robust software architectures, their architectures have to be considered on different architectural levels in order to reduce complexity. Also, the Subsystem modelling element is of great help when delegating and managing responsibility. Best regard, / Tommy Agren (MSc), Enea Realtime. Subject: RE: issue 4619 -- UML RTF issue Date: Wed, 17 Oct 2001 17:15:59 +0200 MIME-Version: 1.0 Message-ID: <2925F4D053DFBE44BC02176424D719BC023F2E@dsserver2.datasim.nl> content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 X-MS-TNEF-Correlator: Thread-Topic: issue 4619 -- UML RTF issue Thread-Index: AcFVqZI0sJDqG8HSSeagWa0eJS3dpQBdDP6w From: "Daniel Duffy" To: "Juergen Boldt" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id f9HF9ie13398 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ^0l!!T3"e9K([!!^mSd9 I personally have difficulty in understanding the concept of *Subsystem* in UML. In my opinion it is a much simplified view of software reality. My question is: does do subsystems come from and are they mapped to objects/components and interfaces? How do I design subsystems? What is the relationship between subsystems and Architectural Design Languages (ADL) etc. What do you mean by a subsystem having operations? What is the relationsship with patterns? Is a package the same as a subsystem? Daniel Duffy > -----Original Message----- > From: Juergen Boldt [mailto:juergen@omg.org] > Sent: 15 October 2001 20:53 > To: issues@emerald.omg.org; uml-rtf@emerald.omg.org > Subject: issue 4619 -- UML RTF issue > > > This is issue # 4619 Tommy Agren > Company: Enea Realtime AB > mailFrom: tommy.agren@enea.se > > Using or implementing an interface of a Subsystem > > Problem: The specification part of the UML Subsystem element does not > consider the two ways to make use of an interface: 1.) Direct > calls. When a > client subsystem should invoke operations of the subsystem. 2.) > Notifications (extensions). When a client subsystem should receive > notifications from the subsystem. > > Note that the static dependency can be directed the same way > in both cases, > but a call can either propagate along or against the > dependency, depending > on what subsystem that is implementing the interface. One-way static > dependencies are crucial when a system should be easy to maintain. > Therefore, one should distinguish between if a client needs > to invoke an > operation of the subsystem (implemented by the subsystem) or > if the client > should implement the interface in order to be notified by the > subsystem. If > needed, I can provide more information about how this can be seen. > > Suggestion: I introduced a usage dependency from the > subsystem border to > the interface in order to show that the subsystem provides > and uses an > interface which is to be implemented by a client subsystem that is to > receive notifications. > > Background: I have been involved in different projects for > Ericsson (the > Telecom Business) and for the Swedish Airforce Defence > Industry. Basically, > the Subsystem modelling element is of great help when modelling large > complex systems, such as Telecom systems for Radio Network > Management. > These systems do not only require robust software > architectures, their > architectures have to be considered on different > architectural levels in > order to reduce complexity. Also, the Subsystem modelling > element is of > great help when delegating and managing responsibility. > > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-781 444 0404 > ext. 132 > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > Needham, MA 02494, USA Email: juergen@omg.org > URL: www.omg.org > > > > ================================================================ > > Reply-To: From: "Kenneth A. Lloyd, Jr." To: "Daniel Duffy" , "Juergen Boldt" Cc: Subject: RE: issue 4619 -- UML RTF issue Date: Wed, 17 Oct 2001 11:14:27 -0500 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <2925F4D053DFBE44BC02176424D719BC023F2E@dsserver2.datasim.nl> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: l!gd9$6pd9JoC!!Nn>!! Daniel: You ask good [read: difficult] questions. I believe a System is a stereotyped extension of a Package [a namespaced collection] consisting of myriad other stuff - including subsystems. If I recall correctly, according to specification, a subsystem is limited in that it cannot contain other subsystems, but I may be wrong on this point. (I don't recall anything about a <> - although packages can contain other packages). A SubsystemInstance being therefore a runtime instance of a subsystem. According to the spec: "A SubsystemInstance may only own Objects, DataValues, Links, UseCaseInstances, CollaborationInstances, SubsystemInstances, and Stimuli." While we are comfortable referring to classes being subclassed or superclassed in terms of abstractness, the semantics could be specific regarding this stereotype. Does anyone else have input on this? Ken Lloyd > -----Original Message----- > From: Daniel Duffy [mailto:dduffy@datasim.nl] > Sent: Wednesday, October 17, 2001 10:16 AM > To: Juergen Boldt > Cc: uml2-wg@omg.org > Subject: RE: issue 4619 -- UML RTF issue > > > I personally have difficulty in understanding the concept of *Subsystem* > in UML. In my opinion it is a much simplified view of software reality. > My question is: does do subsystems come from and are they mapped to > objects/components and interfaces? How do I design subsystems? What is > the relationship between subsystems and Architectural Design Languages > (ADL) etc. What do you mean by a subsystem having operations? What is > the relationsship with patterns? > > Is a package the same as a subsystem? > > > Daniel Duffy > > > -----Original Message----- > > From: Juergen Boldt [mailto:juergen@omg.org] > > Sent: 15 October 2001 20:53 > > To: issues@emerald.omg.org; uml-rtf@emerald.omg.org > > Subject: issue 4619 -- UML RTF issue > > > > > > This is issue # 4619 Tommy Agren > > Company: Enea Realtime AB > > mailFrom: tommy.agren@enea.se > > > > Using or implementing an interface of a Subsystem > > > > Problem: The specification part of the UML Subsystem element does not > > consider the two ways to make use of an interface: 1.) Direct > > calls. When a > > client subsystem should invoke operations of the subsystem. 2.) > > Notifications (extensions). When a client subsystem should receive > > notifications from the subsystem. > > > > Note that the static dependency can be directed the same way > > in both cases, > > but a call can either propagate along or against the > > dependency, depending > > on what subsystem that is implementing the interface. One-way static > > dependencies are crucial when a system should be easy to maintain. > > Therefore, one should distinguish between if a client needs > > to invoke an > > operation of the subsystem (implemented by the subsystem) or > > if the client > > should implement the interface in order to be notified by the > > subsystem. If > > needed, I can provide more information about how this can be seen. > > > > Suggestion: I introduced a usage dependency from the > > subsystem border to > > the interface in order to show that the subsystem provides > > and uses an > > interface which is to be implemented by a client subsystem that is to > > receive notifications. > > > > Background: I have been involved in different projects for > > Ericsson (the > > Telecom Business) and for the Swedish Airforce Defence > > Industry. Basically, > > the Subsystem modelling element is of great help when modelling large > > complex systems, such as Telecom systems for Radio Network > > Management. > > These systems do not only require robust software > > architectures, their > > architectures have to be considered on different > > architectural levels in > > order to reduce complexity. Also, the Subsystem modelling > > element is of > > great help when delegating and managing responsibility. > > > > ================================================================ > > > > Juergen Boldt > > Senior Member of Technical Staff > > > > Object Management Group Tel. +1-781 444 0404 > > ext. 132 > > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > > Needham, MA 02494, USA Email: juergen@omg.org > > URL: www.omg.org > > > > > > > > ================================================================ > > > > > Subject: RE: issue 4619 -- UML RTF issue Date: Thu, 18 Oct 2001 09:02:28 +0200 MIME-Version: 1.0 Message-ID: <2925F4D053DFBE44BC02176424D719BC0445F0@dsserver2.datasim.nl> content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 X-MS-TNEF-Correlator: Thread-Topic: issue 4619 -- UML RTF issue Thread-Index: AcFXPtOjPkJ2d2LGQBClJ49hp+D4KQAY1uTQ From: "Daniel Duffy" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id f9I6uAe01560 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: D'p!!EQ&!!J(g!!Te A SubsystemInstance may only own Objects, DataValues, Links, UseCaseInstances, > CollaborationInstances, SubsystemInstances, and Stimuli." > Something for everyone? The above definition is not so useful for me (it's probably not even wrong) Daniel > -----Original Message----- > From: Kenneth A. Lloyd, Jr. [mailto:kalloyd@wattsys.com] > Sent: 17 October 2001 18:14 > To: Daniel Duffy; Juergen Boldt > Cc: uml2-wg@omg.org > Subject: RE: issue 4619 -- UML RTF issue > > > Daniel: > > You ask good [read: difficult] questions. > > I believe a System is a stereotyped extension of a Package [a > namespaced > collection] consisting of myriad other stuff - including > subsystems. If I > recall correctly, according to specification, a subsystem is > limited in that > it cannot contain other subsystems, but I may be wrong on > this point. (I > don't recall anything about a <> - although packages can > contain other packages). A SubsystemInstance being therefore > a runtime > instance of a subsystem. According to the spec: "A > SubsystemInstance may > only own Objects, DataValues, Links, UseCaseInstances, > CollaborationInstances, SubsystemInstances, and Stimuli." > > While we are comfortable referring to classes being subclassed or > superclassed in terms of abstractness, the semantics could be specific > regarding this stereotype. > > Does anyone else have input on this? > > Ken Lloyd > > > > > -----Original Message----- > > From: Daniel Duffy [mailto:dduffy@datasim.nl] > > Sent: Wednesday, October 17, 2001 10:16 AM > > To: Juergen Boldt > > Cc: uml2-wg@omg.org > > Subject: RE: issue 4619 -- UML RTF issue > > > > > > I personally have difficulty in understanding the concept > of *Subsystem* > > in UML. In my opinion it is a much simplified view of > software reality. > > My question is: does do subsystems come from and are they mapped to > > objects/components and interfaces? How do I design > subsystems? What is > > the relationship between subsystems and Architectural > Design Languages > > (ADL) etc. What do you mean by a subsystem having > operations? What is > > the relationsship with patterns? > > > > Is a package the same as a subsystem? > > > > > > Daniel Duffy > > > > > -----Original Message----- > > > From: Juergen Boldt [mailto:juergen@omg.org] > > > Sent: 15 October 2001 20:53 > > > To: issues@emerald.omg.org; uml-rtf@emerald.omg.org > > > Subject: issue 4619 -- UML RTF issue > > > > > > > > > This is issue # 4619 Tommy Agren > > > Company: Enea Realtime AB > > > mailFrom: tommy.agren@enea.se > > > > > > Using or implementing an interface of a Subsystem > > > > > > Problem: The specification part of the UML Subsystem > element does not > > > consider the two ways to make use of an interface: 1.) Direct > > > calls. When a > > > client subsystem should invoke operations of the subsystem. 2.) > > > Notifications (extensions). When a client subsystem should receive > > > notifications from the subsystem. > > > > > > Note that the static dependency can be directed the same way > > > in both cases, > > > but a call can either propagate along or against the > > > dependency, depending > > > on what subsystem that is implementing the interface. > One-way static > > > dependencies are crucial when a system should be easy to maintain. > > > Therefore, one should distinguish between if a client needs > > > to invoke an > > > operation of the subsystem (implemented by the subsystem) or > > > if the client > > > should implement the interface in order to be notified by the > > > subsystem. If > > > needed, I can provide more information about how this can be seen. > > > > > > Suggestion: I introduced a usage dependency from the > > > subsystem border to > > > the interface in order to show that the subsystem provides > > > and uses an > > > interface which is to be implemented by a client > subsystem that is to > > > receive notifications. > > > > > > Background: I have been involved in different projects for > > > Ericsson (the > > > Telecom Business) and for the Swedish Airforce Defence > > > Industry. Basically, > > > the Subsystem modelling element is of great help when > modelling large > > > complex systems, such as Telecom systems for Radio Network > > > Management. > > > These systems do not only require robust software > > > architectures, their > > > architectures have to be considered on different > > > architectural levels in > > > order to reduce complexity. Also, the Subsystem modelling > > > element is of > > > great help when delegating and managing responsibility. > > > > > > ================================================================ > > > > > > Juergen Boldt > > > Senior Member of Technical Staff > > > > > > Object Management Group Tel. +1-781 444 0404 > > > ext. 132 > > > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > > > Needham, MA 02494, USA Email: juergen@omg.org > > > URL: www.omg.org > > > > > > > > > > > > ================================================================ > > > > > > > > > >