SysML is hard! So it should not be surprising that authors writing on the subject will be faced with a difficult task. To better understand the difficulties we all encounter in mastering SysML, we need look no further than its name. The Sys refers to Systems Engineering. To be a good systems engineer requires, first understanding the technical domains under study. Then systems engineering techniques needs to applied so that a comprehensive understanding of component relationships both among themselves and their environments can be achieved. The ML refers to the Unified Modeling Language (UML) upon which SysML is based. Thus, to understand SysML, one really needs a background in UML. But UML was designed to depict abstractions of object-oriented programs which logically leads to the realization that OO programming experience is also necessary, or at least very helpful. With these prerequisites, OO programming, UML, systems engineering and domain knowledge under your belt, you are ready to master SysML.
The author clearly understands this as the book is largely structured along these lines in six chapters, starting with introductory material related systems engineering. Chapter 2 extends these ideas to a case study showing how various SysML diagrams and features can be brought to bear in understanding a system from various perspectives. This is followed by a chapter on UML as it pertains to SysML. The final two chapters, 62 pages, are devoted to SysML.
I am unsure of the rationale of putting the case study at the beginning as it uses information from subsequent chapters. Readers may find useful to look first at the UML and SysML chapters, and return later to the case study.
The actual text and presentation of information is spotty, good information without a follow-up on its utility. For example, on page 167, we find, "There are associations between classes, links between objects and connectors between roles." This sentence very concisely organizes a vast amount of information by relating similar concepts across different levels of abstraction. However, if you are not aware of abstraction-level notions, this sentence would likely be lost on you. And unfortunately, the author does not pursue this avenue further.
I also found definitions at times less than precise. Consider the definition for the SysML Block element on page 243, "A block describes parts of the structure of a related system. It is a stereotype «block» of the UML element class." I have two problems with this definition. First, readers might assume that structure in the context of a block refers to structural features and in so doing make the assumption that blocks do not encompass behavioral features, which is not true. Second, I do not believe the assertion that a block is a stereotype of class expresses the concept completely.
The definition is followed by additional explanatory text, possibly modifying the definition: "Together with the block, SysML defines an element to be used for describing the static structure of systems." And, "The notation deviates slightly from the standard representation of stereotyped classes." Unfortunately, neither of these sentences seems clear.
By way of comparison, the OMG specification (p33) starts its block definition as follows, "Blocks are modular units of a system description, which define a collection of features to describe a system or other elements of interest. These may include both structural and behavioral features, such as properties and operations, to represent the state of the system and behavior that the system may exhibit." The specification also has the following to say about the relationship between blocks and classes, "SysML blocks are based on UML classes as extended by UML composite structures. Some capabilities available for UML classes, such as more specialized forms of associations, have been excluded from SysML blocks to simplify the language. SysML blocks always include an ability to define internal connectors, regardless of whether this capability is needed for a particular block. SysML Blocks also extend the capabilities of UML classes and connectors with reusable forms of constraints and multi-level nesting of connector ends. SysML blocks include several notational extensions as specified in this chapter."
My criticism is not in that the author is incorrect, rather that the lack of precision, perhaps in the interest of brevity, often makes the material difficult to understand and relate to other information. This would be especially true for readers unfamiliar with the subject area, the target group.
The above notwithstanding, the author provides readers with a considerable amount of information which by-in-large is accessible to a wide audience. Personally, I have found the book valuable, especially when used in conjunction with the OMG specification. Together, I am able to compare/contrast ideas from two perspectives allowing me to achieve deeper understandings of what can often be complex and abstract concepts.
I am sure other texts will appear having better organization, focus and precision. However, these future authors will be building on Tim Weilkiens' work.