Posts Tagged ‘modeling’

Annoying And Disappointing

November 23, 2012 4 comments

Atego’s Artisan Real-Time Studio, Sparx’s Enterprise Architect, and IBM’s Rational Rhapsody are big and expensive UML  modeling tools. You would think they support all of the basic visual modeling elements of the UML, no?

On the left side of the figure below, I show the four fundamental, visual UML symbols for conjuring up (wrong, incomplete, and inconsistent) structural views of an object-oriented software system in the form of class diagrams, deployment diagrams, component diagrams, etc.

It blows BD00’s already incoherently twisted mind that Artisan Studio doesn’t provide visual elements for a UML Node or a Component. As can be seen on the right side of the figure, the work-around is to use stereotyped Classifier elements to fill the void. It’s annoying and disappointing, dontcha think?

But hey, not many people (especially extreme left-wing agile zealots) buy into the potential of the UML for shortening the development time and long-term cost of big, sprawling, long-lived software systems . So, “meh” to this irrelevant post.

Note: I’m a relatively newbie user of Artisan Studio. If you’re an advanced user and you know that I’m mistaken here, then please speak up and tell me how to find these two seemingly-hidden buggers.


October 13, 2012 Leave a comment

Unsurprisingly, one of BD00’s posts irritated a reader who stumbled upon it. For some strange reason, BD00’s scribblings have that effect on some people. In the irritating post, “The Old Is New Again“, BD00 referred to Data and Control Flow diagrams as “old and obsolete“. In caustic BD00 fashion, the reader commented:

Use Cases and Activity Diagrams, in contrast (to the Data Flow diagram), offer little guidance in effective partitioning. They rely upon the age old “sledge hammer” approach to partitioning” (ie, just break-er-up any way you can). Sledge hammer partitioning is what cave men used to partition entities. So in a critical sense, DFD’s are new and hip, while Use Cases and Activity Diagrams are based upon logic that is older than dirt.

BD00 likes all visual modeling tools – including the DFD hatched during the heyday of structured analysis. BD00 only meant “old and obsolete” in the sense that DFDs pre-dated the arrival of the UML and the object-oriented approach to system analysis and design. However, BD00 did feel the need to correct the reader’s misunderstanding of the features and capabilities that UML Activity Diagrams offer up to analysts/designers.

Both the DFD and UML activity diagram pair below equivalently capture an analyst’s partitioning design decision (where DFD Process X == Activity Diagram Action X). Via “swimlanes“, the lower activity diagram makes the result of a second design decision visible: the conscious allocation of the Actions to the higher level Objects that will perform them during system operation. So, how are UML activity diagrams inferior to DFDs in supporting partitioning? A rich palette of other symbols (forks, joins, decisions, merges, control flows, signals) are also available to analysts (if needed) for capturing design decisions and exposing them for scrutiny.

DFDs and UML diagrams are just tools – job performance aids. Learning how to use them, and learning how to use them effectively, are two separate challenges. Design “guidance” for system partitioning, leveling, balancing, etc, has to come from somewhere else. From a mentor? From personal experience learning how to design systems over time? From divine intervention?

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

UML and SysML Behavior Modeling

August 29, 2009 2 comments

Most interesting systems exhibit intentionally (and sometimes unintentionally) rich behavior. In order to capture complex behavior, both the UML and its SysML derivative provide a variety of diagrams to choose from. As the table below shows, the UML defines 7 behavior diagram types and the SysML provides a subset of 4 of those 7.

Behavior Diags

Activity diagrams are a richer, more expressive enhancement to the classic, stateless, flowchart. Use case diagrams capture a graphical view of high level, text-based functional requirements. State machine diagrams are used to model behaviors that are a function of current inputs and past history. Sequence diagrams highlight the role of “time” in the protocol interactions between SysML blocks or UML objects.

What’s intriguing to me is why the SysML didn’t include the Timing diagram in its behavioral set of diagrams. The timing diagram emphasizes the role of time in a different and more precise way than the sequence diagram. Although one can express precise, quantitative timing constraints on a sequence diagram, mixing timing precision with protocol rules can make the diagram much more complicated to readers than dividing the concerns between a sequence diagram and timing diagram pair. Exclusion of the timing diagram is even more mysterious to me because timing constraints are very important in the design of hard/soft real-time systems. Incorrect timing behavior in a system can cause at least as much financial or safety loss as the production of incorrect logical outputs. Maybe the OMG and INCOSE will reconsider their decision to exclude the timing diagramin their next SysML revision?

%d bloggers like this: