First, let me say that I had to use this book for several months before I became quite fond of it. It's not an easy read, but how it is best used in my opinion is while working a task, especially if one is using a CASE tool such as MagicDraw for a challenging project. I read and agree with most of what Ted Kahn said in his review but as you use this text on a real project, some of the "less precision" becomes not as important. The author's start with the SYSMOD approach was a bit confusing to me (why start here?) until I actually had to work a requirements project in SysML and then it made sense. I actually modeled a couple of his SYSMOD diagrams in my case tool, just to get used to how to use the CASE tool and to study a bit on his system engineering methods. I now use some of those diagrams as explanations of how I am modeling things.

I find his explanations of requirements, use cases, flows, ports and pins most helpful. I also find the example cases that he gives with the actual SysML diagrams very useful. In summary, it took me some time to warm up to this book but now it stays with me wherever I go and if I have a spare moment, I will be in it with my highlighter and 0.7mm mechanical pencil marking up text and dog earing pages. What I do appreciate is the fact that Mr. Weilkiens got some something to market that is very helpful in a timely manner.

I look forward to the next revision.

F.C. Alvidrez, CEA
Lancaster, CA

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.