| || |
Systems Engineering with SysML/UML: Modeling, Analysis, Design (The MK/OMG Press)
Availability: Usually ships in 24 hours
Ships from and sold by Amazon.com
(4 customer reviews)
UML, the Universal Modeling Language, was the first programming language designed to fulfill the requirement for "universality." However, it is a software-specific language, and does not support the needs of engineers designing from the broader systems-based perspective. Therefore, SysML was created. It has been steadily gaining popularity, and many companies, especially in the heavily-regulated Defense, Automotive, Aerospace, Medical Device and Telecomms industries, are already using SysML, or are plannning to switch over to it in the near future.
However, little information is currently available on the market regarding SysML. Its use is just on the crest of becoming a widespread phenomenon, and so thousands of software engineers are now beginning to look for training and resources. This book will serve as the one-stop, definitive guide that provide an introduction to SysML, and instruction on how to implement it, for all these new users.
*SysML is the latest emerging programming language--250,000 estimated software systems engineers are using it in the US alone!
*The first available book on SysML in English
*Insider information! The author is a member of the SysML working group and has written sections of the specification
*Special focus comparing SysML and UML, and explaining how both can work together
- Amazon Sales Rank: #1371096 in Books
- Published on: 2008-02-26
- Released on: 2008-02-12
- Original language: English
- Number of items: 1
- Dimensions: 9.50" h x .73" w x 7.50" l, 1.51 pounds
- Binding: Paperback
- 320 pages
About the Author
Tim Weilkiens is a Managin Director of oose Innovative Informatik GmbH. He is the author of numerous books and other publications and content development of the OCEB certification program.
Most helpful customer reviews
12 of 12 people found the following review helpful.
After using this book for a couple months, I like it a lot.
By Frank C. Alvidrez
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
0 of 8 people found the following review helpful.
Happy Customer (5-stars) !!
By Dave H
This purchased product (Book: Systems Engineering with SysML/UML) was as advertised (great reference). I rate this product and this Amazon purchase experience as 5-stars !!
20 of 20 people found the following review helpful.
Solid effort, worth reading
By Theodore Kahn
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.