Understanding definition & use.
Object Oriented principles provide some powerful techniques for defining families of systems. These have been around these so long that to many engineers they seem obvious, almost second nature. Two OO principles that I find particularly useful are composition and generalization, which SysML combines together in an approach to structural hierarchy. The implication of this concept in SysML is something that the author usually refer to as “definition vs. Use“.
Internal block diagrams (ibds) are all about use. They depict the interconnection connection of “parts” within the context of the containing block represented by the diagram frame. This diagram shows that the block Anti-Lock Controller is composed of part d1 and part m1 connected by the connector c2, with d1 giving/sending something and m1 taking/receiving something. It further shows that d1 is a Traction Detector, and m1 is a Brake Modulator. It does not define what Traction Detector or Brake Modulator mean.
Block definition diagrams (bdds) are, as the name implies, all about definition. They define context-invariant relationships and attributes, including “is a” (Brake Modulator is a Electro-Hydraulic Valve) and “has a” (Anti-Lock Controller has a Traction Detector and a Brake Modulator). “Is a” is generalization, “has a” is composition.
“Definition vs. Use” seems to be the biggest “stumbling block” for new SysML users that don’t already have a software background. They can even be problematic for some OO savvy people! Any introductory SysML class will usually have at least one question along the lines of “Why do I need BOTH a bdd and an ibd?” The notions in each diagram seem to overlap. The diagrams seem to be redundant. If the student is experiencing too much frustration with this concept, a fruitful response has been… “If you need to ask the question, just build the ibd and be done with it!” Once they have built a suitably complex model, the role of the bdd will naturally become clear.
Generalization and composition aren’t necessary to define a system. Ibds are intuitive analogs to the old, familiar “system block diagrams” that systems engineers have been using since before there were computers. Bdds are NOT mandatory, but you will eventually want them. Why? Because you get tired of fixing the large number of ibds that you have generated. You get tired of having to go into each ibd and update the name of a part or port specification so that it is consistent with a new design change. As soon as someone asks “Couldn’t we just have all the part names in one place, and collect together all the ones that are basically the same?” then they are ready to build their first bdd! Yes, building the bdd later will cause some rework. It is always more efficient to build them first, before the ibds… But that’s not always appropriate for students trying to learn SysML for the first time!
Bdds and ibds are complimentary aspects of a single structural model. This definition-use paradigm applies more broadly than just structure, however. It also applies to parametric & activity models, and in SysML 1.4 will apply even more broadly. Activity models and functional hierarchy will be discussed in a subsequent section.
The real efficiency of definition-use can be summarized as follows:
- Define an element in only one place in the model.
- Use it everywhere it is needed. Don’t redefine it unless you need to.
Mechanical engineers tend to have fewer problems with this concept. They are used to the idea of establishing a parts list first, and to the idea that they must choose their parts from some kind of parts library.
Awesome! That makes sense now. Thanks.
More at: http://www.jot.fm/issues/issue_2004_11/column5. Before UML at http://conradbock.org/#Composition.