We've seen in a previous slide some of the possible compartments on a Block symbol in a BDD; now it's time to see some Relationships between more than one Block on a BDD. Our example problem for this part of the trail is a Home Entertainment System, starting with the TV:

Click on the image to view it full size

The Block TV is abstract:

UML-2.5.1: 'Classifier::isAbstract : Boolean [1..1] If true, the Classifier can only be instantiated by instantiating one of its specializations. An abstract Classifier is intended to be used by other Classifiers e.g., as the target of Associations or Generalizations'

It has Associations to other Blocks Speaker and Screen that are likewise abstract:

Webel Best Practice: If an abstract Block or Class in a domain model has Associations to Blocks or Classes that are not also abstract, it's often a hint that you have not identified a correct abstraction layer.

The Speaker and Screen are part properties owned by the TV block:

SysML-1.6: 'A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special case of a constraint property ...'

Webel Best Practice: A common interpretation of composite Aggregation of a part property in SysML domain modelling is that if the owner Block is "destroyed" so is the child part property. Webel adopts these semantics always.

It is specified here that the TV has at least one [1..*] internal speaker:Speaker and exactly one screen:Screen according to this rule:

SysML-1.6: 'SysML defines defaults for multiplicities on the ends of specific types of associations. A part or shared association has a default multiplicity of [0..1] on the black or white diamond end. A unidirectional association has a default multiplicity of 1 on its target end.'

The abstract block TV is a generalization of the concrete specializations block HD_TV and block UHD_TV. (In reality of course one might have variations on HD and UHD TVs, but making them concrete here is sufficient for this example.)

The following Webel Best Practice block naming option has been used here (we'll see some other alternatives later):

Webel Best Practice: When using acronyms in names of Classifiers either treat them as a word 'TlaLikeThis' or suffix with an underscore 'TLA_LikeThis', except at the end of the name 'LikeThisTLA' is admissable.

And in case there are any inheritance-loathing software elephants in the room:

When domain modelling with SysML, Generalization, inheritance, and even multiple inheritance are not "evil" and can be used relatively freely. We are not doing code-oriented Decorator patterns - an implementation choice - we are doing domain modelling!

So extend happily away (at least for now)!

Up next

SysMLv1 Part Property representations

Notes

[ASSERTION, TIP]{STRONG} If an abstract Block or Class in a domain model has Associations to Blocks or Classes that are not also abstract, it's often a hint that you have not identified a correct abstraction layer.

[]{STRONG} A common interpretation of composite Aggregation of a part property in SysML domain modelling is that if the owner Block is "destroyed" so is the child part property. Webel adopts these semantics always.

[ASSERTION]{STRONG} When domain modelling with SysML, Generalization, inheritance, and even multiple inheritance are not "evil" and can be used relatively freely. We are not doing code-oriented Decorator patterns - an implementation choice - we are doing domain modelling!

[NAMING, POLICY]{STRICT} DO NOT use spaces in Property names or Class/Block names! If you want to communicate familiar names of elements within an organisation use a custom stereotype and tagged values (such as 'aka')!