Archive

Posts Tagged ‘sysml’

Scrumming For Dollars

December 5, 2011 Leave a comment

Systems Engineering with SysML/UML” author Tim Weilkiens recently tweeted:

Tim’s right. Check it out yourself: Scrum Guide – 2011.

Before Tim’s tweet, I didn’t know that “software” wasn’t mentioned in the guide. Initially, I was surprised, but upon further reflection, the tactic makes sense. Scrum creators Ken Schwaber and Jeff Sutherland intentionally left it out because they want to maximize the market for their consulting and training services. Good for them.

As a byproduct of synthesizing this post, I hacked together a UML class diagram of the Scrum system and I wanted to share it. Whatcha think? A useful model? Errors, omissions? Does it look like Scrum can be applied to the development of non-software products?

SysML Support For Requirements Modeling

“To communicate requirements, someone has to write them down.” – Scott Berkun

Prolific author Gerald Weinberg once said something like: “don’t write about what you know, write about what you want to know“. With that in mind, this post is an introduction to the requirements modeling support that’s built into the OMG’s System Modeling Language (SysML). Well, it’s sort of an intro. You see, I know a little about the requirements modeling features of SysML, but not a lot. Thus, since I “want to know” more, I’m going to write about them, damn it! 🙂

SysML Requirements Support Overview

Unlike the UML, which was designed as a complexity-conquering job performance aid for software developers, the SysML profile of UML was created to aid systems engineers during the definition and design of multi-technology systems that may or may not include software components (but which interesting systems don’t include software?). Thus, besides the well known Use Case diagram (which was snatched “as is” from the UML) employed for capturing and communicating functional requirements, the SysML defines the following features for capturing both functional and non-functional requirements:

  • a stereotyped classifier for a requirement
  • a requirements diagram
  • six types of relationships that involve a requirement on at least one end of the association.

The Requirement Classifier

The figure below shows the SysML stereotyped classifier model element for a requirement. In SysML, a requirement has two properties: a unique “id” and a free form “text” field. Note that the example on the right models a “non-functional” requirement – something a use case diagram wasn’t intended to capture easily.

One purpose for capturing requirements in a graphic “box” symbol is so that inter-box relationships can be viewed in various logically “chunked“, 2-dimensional views – a capability that most linear, text-based requirements management tools are not at all good at.

Requirement Relationships

In addition to the requirement classifier, the SysML enumerates 6 different types of requirement relationships:

A SysML requirement modeling element must appear on at least one side of these relationships with the exception of  <<derivReqt>> and <<copy>>, which both need a requirement on both sides of the connection.

Rather than try to write down semi-formal definitions for each relationship in isolation, I’m gonna punt and just show them in an example requirement diagram in the next section.

The Requirement Diagram

The figure below shows all six requirement relationships in action on one requirement diagram. Since I’ve spent too much time on this post already (a.k.a. I’m lazy) and one of the goals of SysML (and other graphical modeling languages) is to replace lots of linear words with 2D figures that convey more meaning than a rambling 1D text description, I’m not going to walk through the details. So, as Linda Richman says, “tawk amongst yawselves“.

References

1) A Practical Guide to SysML: The Systems Modeling Language – Sanford Friedenthal, Alan Moore, Rick Steiner

2) Systems Engineering with SysML/UML: Modeling, Analysis, Design – Tim Weilkiens

SysML, UML, MML

May 27, 2011 2 comments

I really like the SysML and UML for modeling and reasoning about complex, multi-technology and software-centric systems respectively, but I think they have one glaring shortcoming. They aren’t very good at modeling distributed, multi-process, multi-threaded systems. Why? Because every major element (except for a use case?) is represented as a rectangle. As far as I know, a process can be modeled as either a parallelogram or a stereotyped rectangular UML class (SysML block ):

To better communicate an understanding of multi-threaded, multi-process systems, I’ve created my own graphical “proprietary” (a.k.a. homegrown) symbology. I call it the MML (UML profile). Here is the MML symbol set.

An example MML diagram of a design that I’m working on is shown below. The app-specific modeling element names have been given un-descriptive names like ATx, APx, DBx, Mx for obvious reasons.

Compare this model with the equivalent rectangular UML diagram below. I purposely didn’t use color and made sure it was bland so that you’d answer the following question the way I want you to. Which do you think is more expressive and makes for a better communication and reasoning tool?

If you said “the UML diagram is better“, that’s OK. 🙂

Domain, Infrastructure, And Source

October 26, 2010 Leave a comment

Via a simple SysML diagram that solely uses the “contains” relationship icon (the circled crosshairs thingy) , here’s Bulldozeroo’s latest attempt to make sense of the relationships between various levels of abstraction in the world of software as he knows it today. Notice that in Bulldozer00’s world, where the sky is purple, the architecture is at the center of the containment hierarchy.

Unconstraining UML And SysML Modeling Tools

October 9, 2010 Leave a comment

For informal, rapid, and iterative design modeling and intra-team communication, I use the freely downloadable and unconstraining UML and SysML stencil plugins for visio. These handy little stencils are available here: Visio UML and SysML stencils homepage. When installed and opened, the shapes window may look like the figure below. Of course, you can control which shapes sub-windows you’d like to display and use within a document via the file->shapes menu selection. Open all 11 of them if you’d like!

If you compare the contents of the two sets of shape stencils, since UML is a subset and extension of UML you’ll unsurprisingly find a lot of overlap in the smart symbol sets. Note that unlike the two UML stencils, the set of nine SysML stencils are “SysML Diagram” oriented. Because of this diagram-centric decomposition, I find myself using the SysML stencils more than the UML stencils.

To use the stencils, you just grab, drag, and drop symbols onto the canvas; tying them together with various connector symbols. Of course, each symbol is “smart”, so right-clicking on a shape triggers a context sensitive menu that gives you finer control over the attributes and display properties of the shape.

If you don’t want to open the stencils manually, you can create either a new SysML or UML document from the templates that are co-installed with the stencils (file->new->choose drawing type->SysML). In this case, either the 2 UML stencils, or all 9 SysML stencils are auto-opened when the first page of the new document is created and displayed. I often use the multi-page feature of visio to create a set of associated behavior and structure diagrams for the design that I’m working on, or to reverse-engineer a section of undecipherable code that I’m struggling to understand.

If you’re a visio user and you’re looking to learn UML and/or SysML, I think experimenting with these stencils is a much better learning alternative than using one of the big, formal, and more hand-cuffing tools like Artisan Studio or Sparx Enterprise Architect. You can “Bend it like Fowler” much more easily with the visio stencils approach and not get frustrated as often.

ICONIX SysML Training Postscript

Since I’ve noticed that my ICONIX SysML training preview post has received quite a few hits over the past several months and I haven’t written a followup post, I decided that now is the time to do it.

The Bad

When the course was over, I felt very disappointed. Instead of focusing on SysML – which is embedded in the title of the course, SysML was given second class treatment and the main thrusts were centered on:

  • Teaching the usage of the big and sprawling Enterprise Architect software modeling and code generation tool
  • Teaching a “bent”,  non-standard, subset of  UML that supports ICONIX’s homegrown software design process: “Use Case Driven Object Modeling

Only the last (not first) one third of the class handout covered the SysML diagrams and symbolology while the first two thirds covered UML, albeit in a subserviant role to the ICONIX process.

The Good

Although the examples in the handout material were all geared toward database-centric business transaction systems, but my company is in the business of building real-time sensor systems, the teachers facilitated the real time development of a set of use cases, robustness diagrams, and class diagrams for the sensor project we were kicking off. It was a worthwhile team building experience and it surfaced a boatload of ambiguities and misunderstandings between team members. The teachers were skilled facilitators and they did a great job keeping things moving briskly while remaining in the background and not dominating the working sessions.

The Summary

Jumpin’ Out

If you’re deeply embedded in a complex social system, it’s incredibly difficult to gain any insight into what the system you’re enmeshed in really does, or how it does what it does. Even though you’re an integral element of the system, your view is most likely obscured by your lack of interest in finding out or, more likely, by a lack of communication from the dudes in the penthouse. All you can see are trees. No forest, and no sun above the treetops.

A great way of “jumping out of the system” to get a better view and understanding is by modeling. By taking a stab at modeling the static structures and dynamic behaviors of the system you’re in, you can get a much better feel for what’s going on.

A formal language like UML or SysML paired with a good visual drawing tool like Visio can be a powerful tool set to help you gain perspective, but all you really need is a pencil and paper to start things off. Since your first few iterations will suck and be totally wrong, you’ll be throwing away lots of wood pulp if you don’t use an electronic tool. If you stick with it, you’ll acquire an understanding of what really happens in your system as opposed to what is espoused by those in charge.

All models are wrong, but some are useful. – George Box

%d bloggers like this: