Loving SysML

Since some weeks I am working with SysML, the special UML profile for Systems Engineering. It uses the most important diagrams of the UML, like Use Case, Activity, Class Diagram, and introduces some additional, like Block diagram and Requirement diagram. The more I work with it, the more I like it because for system engineers it has some advantages over standard UML 2.0:

• The concept of <<blocks>> is more flexible to use. It has class semantics, so it can have attributes like subblocks and parts, and the aggregation and composition semantics. On the other side, a block can be a broad set of things: a feature, a software or hardware component, an functional element. A block itself can be bind on parameters, equations, constraints and other. Therefore, it is a little bit more flexible than the <<component>> of standard UML. And this is, to what a systems engineer is often faced to: very differenct functional elements, which can be a physical thing, a device or a logical set of harware and software, and which are not easily match the classic categories of pure software engineering.
  
• In SysML you can model requirements. You can relate them to each other, for example with <<refine>> You can bind them on Use Cases, on Activities and Blocks and make your solution simple traceable. Using the right tool, you can exchange requirements with Telelogic DOORS (R) and other requirement management systems. 
  
• By using the <<allocate>>, it is possible to relate elements of a conceptual level to elements of the implementation level in a simple way. So you can describe which element in the system is introduced ("allocated") because of which feature described by the concept or requirement. The consequence: bidirectional tracability is easy to maintain.
  
• These simple but powerful constructs make it easy to model product lines: because a block can be many things, it also usable for setting up feature diagrams. Applying some additional stereotypes like <<optional>> or <<variationpoints>> to blocks and using the <<allocation>> and <<satisfy>> mechanism, a variant configurations can be documented and can be mapped to the implementation level. And that's it !

One word about tools: UML or any profile from it will be used by using a special software. Of course, sometimes you write on whiteboards or paper. But for real-world complete models, a software is needed. A good software ! If this has some useful features and good support of the Metamodell of UML, working with UML as a tool comes close to what CAD is to mechanics engineering: the model will not be just a collecton of pictures, of static documentation, it will be a complex database of knowledge, which can be modified, worked with, to which queries can be addressed.

For example, I have set up a empty UseCase diagram, and if I want to add assozations, or I want to find out which model element is connected to which other (a "query"), I drag the elements in question into the diagram. Now I have all functions needed in the context menu of the elements, and can perform my task. After this, I make the diagram empty, which does not delete the model elements, though. The empty diagram is like the texteditor, or the query interface for a database.

What I want to express is, that the way how one works with UML is influenced hard by the comfort and strengh of the software in use. Using UML as a language, as a knowledge constructor and maintainer, not as just a notation to document things, is possible, if the software is good, and only then UML let access the engineer the real power of itself.