Author Topic: Information Flow vs. Dependency Relationship  (Read 1324 times)

Stephen Kropp

  • EA User
  • **
  • Posts: 27
  • Karma: +1/-0
    • View Profile
Information Flow vs. Dependency Relationship
« on: October 28, 2016, 03:19:09 am »
I am working on a SysML Block Definition Diagram to display the as-is relationship of actors within my system. For my example let's call one of the actors the "Service Department" with a generalization to the second actor called a "Field Service Technician".

I have an information flow depicted between the two actors, as well as a dependency relationship between the same two actors.

I am trying to convey that the Service Department depends on the Field Service Technician to complete a task. The task is conveyed between the two actors via an information flow "Request for Onsite Service".

My question: Is a dependency relationship implied by the information flow? Can I delete the dependency flow and instead rely on the information flow to convey the same meaning without cluttering up the diagram?

Maybe the answer lies in the multiplicity details, because the Service Department (multiplicity = 1) depends on multiple Field Service Technicians (multiplicity = *), but the information flow between the Service Department (multiplicity = 1) would depend on one Field Service Technician (multiplicity = 1). Since this seems like an important part of the context, I would lean in favor of keeping the dependency relationship and the information flow depicted on the block definition diagram.

Thanks,

Steve
« Last Edit: October 28, 2016, 04:23:32 am by Stephen Kropp »

qwerty

  • EA Guru
  • *****
  • Posts: 8972
  • Karma: +136/-124
  • I'm no guru at all
    • View Profile
Re: Information Flow vs. Dependency Relationship
« Reply #1 on: October 28, 2016, 06:41:20 am »
A dependency is the weakest connector (leaving out the note connector) and any higher order association implies a dependency. If A is associated with B there's also a dependency between both, depending on used roles and/or navigability and/or ownership. An information flow has even more dependencies (namely between the objects where the flow happens and the objects which are conveyed).

q.

Stephen Kropp

  • EA User
  • **
  • Posts: 27
  • Karma: +1/-0
    • View Profile
Re: Information Flow vs. Dependency Relationship
« Reply #2 on: October 28, 2016, 07:41:49 am »
Thanks Qwerty, with that being said. Would you take the time to clean out lower-order relationships from the model when a higher-order relationship is created?

qwerty

  • EA Guru
  • *****
  • Posts: 8972
  • Karma: +136/-124
  • I'm no guru at all
    • View Profile
Re: Information Flow vs. Dependency Relationship
« Reply #3 on: October 28, 2016, 08:30:51 am »
Well, probably yes and using a simple script. But it's not necessary since having the additional dependency is not wrong per se. But it might cause issues.

In my projects I used to have a couple of consistency checks being run regularly. One of the routines therein could well have been such a connection check.

q.

Slávek Rydval

  • EA Novice
  • *
  • Posts: 16
  • Karma: +1/-0
    • View Profile
    • homepage
Re: Information Flow vs. Dependency Relationship
« Reply #4 on: November 01, 2016, 07:49:40 am »
I think you mixed more things together. Dependency can be seen almost everywhere (for instance, if an attribute has a type you can say that this attribute depends on its type). Dependency is the most general metaclass used usually to say: I won't to specify it more precious (which doesn't mean it is wrong).

On the other hand, flow means that a piece of data flows from source to target. It doesn't say anything else such as who starts the transfer. Secondly, information flow is not (from UML point of view) a specialization of dependency.

Last but not least, multiplicity has nothing to do with dependency neither with information flow.

To sum it up: if you use information flow, there is no need to use dependency. Using multiplicity with dependency or information flow is against UML 2 standard. I would definitely delete the dependency if there is an information flow.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5882
  • Karma: +71/-79
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Information Flow vs. Dependency Relationship
« Reply #5 on: November 01, 2016, 10:38:39 am »
[SNIP]

Last but not least, multiplicity has nothing to do with dependency neither with information flow.

[SNIP]
While accepting UML Dependency has no concept of multiplicity, I'm not so sure that multiplicity has no place in a Dependency.

The first question is:  Is Dependency (in the abstract) a relationship between classifiers or (like normal Associations - as opposed to some specialized Associations) is it expressing a relationship between instances of the classifier.  If the latter, then there might be a place for multiplicity in the relationship.  You may wish to express constraints onthe semantics of the dependency.  We've experimented with allowing users to express non-standard multiplicities for Dependency.

Just some thoughts,
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Slávek Rydval

  • EA Novice
  • *
  • Posts: 16
  • Karma: +1/-0
    • View Profile
    • homepage
Re: Information Flow vs. Dependency Relationship
« Reply #6 on: November 01, 2016, 10:24:25 pm »
You have to distinguish between UML standard and UML in EA. In UML standard has Dependency really nothing in common with Multiplicity. In comparison with UML standard, EA allows you to break many UML rules (constraint).

Dependency is not a relationship between Classifiers but NamedElements (thus you can have dependency e.g. between attributes). As UML states:

Quote
A Dependency implies that the semantics of the clients are not complete without the suppliers. The presence of Dependency relationships in a model does not have any runtime semantic implications. The semantics are all given in terms of the NamedElements that participate in the relationship, not in terms of their instances.

Dependency is a specialization of DirectedRelationship.

Association is a specialization of Relationship and Classifier. Association has any number of ownedEnds (of metatype Property) and specifies a relationship between instances of these properties.

In my own UML life I try to omit using pure dependency. There are specialization such as Using or Realization whose semantics is more concrete. If a class calls an operation in other class, I use Usage. On the other hand, if a class is in an association with other one (such as Person has BankAccount), I use Association.