Archive

Archive for the ‘uml’ Category

Mind-To-Code-To-Mind And Mind-To-Model-To-Code

April 27, 2017 Leave a comment

Since my previous post, I’ve been thinking in more detail about how we manage to move an integrated set of static structures and dynamic behaviors out of our heads and into a tree of associated source code files. A friend of mine, Bill Livingston, coined this creative process as “bridging the gap” across the “Gulf Of Human Intellect” (GOHI).

The figure below shows two methods of transcending the GOHI: direct mind-to-code (M2C), and indirect mind-to-model-to-source (M2M2C). The difference is that M2M2C is scale-able where as M2C is not. Note that both methods are iterative adventures.

Past a certain system size (7 +/- 2 interconnected chunks?), no one can naturally fit a big system model entirely within their head without experiencing mental duress. By employing a concrete model as a “cache” between the mind and the code, M2M2C can give large performance and confidence boosts to the mind. But, one has to want to actively learn how to model ideas in order to achieve these benefits.

From Mind-To-Code (M2C)

How do we grow from a freshly minted programmer into a well-rounded, experienced, software engineer? Do we start learning from the top-down about abstract systems, architecture, design, and/or software development processes? Or do we start learning from the bottom up about concrete languages, compilers, linkers, build systems, version control systems?

It’s natural to start from the bottom-up; learning how to program “hands on“. Thus, after learning our first language-specific constructs, we write our first “Hello World” program. We use M2C to dump our mind’s abstract content directly into a concrete main.cpp  file via an automatic, effortless, Vulcan mind-meld process.

Next, we learn, apply, and remember over time a growing set of language and library features, idioms, semantics, and syntax. With the addition of these language technical details into to our mind space, we gain confidence and we can tackle bigger programming problems. We can now hold a fairly detailed vision of bigger programs in our minds – all at once.

From Mind-To-Model-To-Code (M2M2C)

However, as we continue to grow, we start to yearn of building even bigger, more useful, valuable systems that we know we can’t hold together in our minds – all at once. We turn “upward“, stretching our intellectual capabilities toward the abstract stuff in the clouds. We learn how to apply heuristics and patterns to create and capture design and architecture artifacts.

Thus, unless we want to go down the language lawyer/teacher route, we learn how to think outside of the low level “language space“. We start thinking in terms of “design space“, creating cohesive functional units of structure/behavior and the mechanisms of loosely connecting them together for inter-program and intra-program communication.

We learn how to capture these designs via a modeling tool(s) so we can use the concrete design artifacts as a memory aid and personal navigational map to code up, integrate, and test the program(s). The design artifacts also serve double duty as communication aid for others. Since our fragile minds are unreliable, and they don’t scale linearly, the larger the system (in terms of number of units, types of units, size of units, and number of unit-to-unit interfaces), the more imperative it is to capture these artifacts and keep them somewhat in synch with the fleeting images we are continuously munching on in our mind.

We don’t want to record too much detail in our model because the overhead burden would be too great if we had to update the concrete model artifacts every time we changed a previous decision. On the other hand, we don’t want to be too miserly. If we don’t record “just enough” detail, we won’t be able mentally trace back from the artifacts to the “why?” design decisions we made in our head. That’s the “I don’t know why that’s in the code base or how we got here” syndrome.

A Useful Design Tool

For a modeling tool, we can use plain ole paper sketches that use undecipherable “my own personal notation“, or we can use something more rigorous like basic UML diagrams.

For example, take the static structural model of a simple 3 class design in this UML class diagram:

I reverse-engineered this model out of a small section of the code base in an open source software project. If you know UML, you know that the diagram reads as:

  • A CBlockis aCBlockHeader.
  • A CBlockhas” one or more CTransactionRef objects that it creates, owns, and manages during runtime
  • A CBlockHeaderhas” several data members that it creates, owns, and manages during runtime.

Using this graphic artifact, we can get to a well structured skeleton code base better than trying to hold the entire design in our head at once and then doing that Vulcan mind meld thingy directly to code again.

Using the UML class diagram, I coded up the skeletal structure of the program as three pairs of .h + .cpp files. Some UML tools can auto-generate the code skeletons at the push of a button after the model(s) have been manually entered into the tool’s database. But that would be a huge overkill here.

As a sanity-test, I wrote a main.cpp file that simply creates and destroys an object of each type:

From Mind-To-Model-To-Code: Repeat And Rise

For really big systems, the ephemeral, qualitative, “ilities” and “itys” tend to ominously pop up out of the shadows during the tail end of a lengthy development effort (during the dreaded system integration & testing phases). They suddenly, but understandably, become as important to success as the visible, “functional feature set“.  After all, if your system is dirt slow (low respons-ivity), and/or crashes often (low reliab-ility ), and/or only accommodates half the number of users as desired (low scala-bility), no one may buy it.

So, in summary, we start out as a junior programmer with limited skills:

Then, assuming we don’t stop learning because “we either know it all already or we’ll figure it out on the fly” we start transforming into a more skilled software engineer.

Categories: technical, uml Tags:

Big Design, But Not All Upfront

December 8, 2013 Leave a comment

When not ranting and raving on this blawg about “great injustices” (LOL) that I perceive are keeping the world from becoming a better place, I design, write, and test real-time radar system software for a living. I use the UML before, during, and after coding to capture, expose, and reason about my software designs. The UML artifacts I concoct serve as a high level coding road map for me; and a communication tool for subject matter experts (in my case, radar system engineers) who don’t know how to (or care to) read C++ code but are keenly interested in how I map their domain-specific requirements/designs into an implementable software design.

I’m not a UML language lawyer and I never intend to be one. Luckily, I’m not forced to use a formal UML-centric tool to generate/evolve my “bent” UML designs (see what I mean by “bent” UML here: Bend It Like Fowler). I simply use MSFT Visio to freely splat symbols and connections on an e-canvas in any way I see fit. Thus, I’m unencumbered by a nanny tool telling me I’m syntactically/semantically “wrong!” and rudely interrupting my thought flow every five minutes.

The 2nd graphic below illustrates an example of one of my typical class diagrams. It models a small, logically cohesive cluster of cooperating classes that represent the “transmit timeline” functionality embedded within a larger “scheduler” component. The scheduler component itself is embedded within yet another, larger scale component composed of a complex amalgam of cooperating hardware and software components; the radar itself.

Hostile Environment

When fully developed and tested, the radar will be fielded within a hostile environment where it will (hopefully) perform its noble mission of detecting and tracking aircraft in the midst of random noise, unwanted clutter reflections, cleverly uncooperative “enemy” pilots, and atmospheric attenuation/distortion. But I digress, so let me get back to the original intent of this post, which I think has something to do with how and why I use the UML.

The radar transmit timeline is where other necessarily closely coupled scheduler sub-components add/insert commands that tell the radar hardware what to do and when to do it; sometime in the future relative to “now“. As the radar rotates and fires its sophisticated, radio frequency pulse trains out into the ether looking for targets, the scheduler is always “thinking” a few steps ahead of where the antenna beam is currently pointing. The scheduler relentlessly fills the TxTimeline in real time with beam-specific commands. It issues those commands to the hardware early enough for the hardware to be able to queue, setup, and execute the minute transmit details when the antenna arrives at the desired command point. Geeze! I’m digressing yet again off the UML path, so lemme try once more to get back to what I originally wanted to ramble about.

TxTimeline UML

Being an unapologetic UML bender, and not a fan of analysis-paralysis, I never attempt to meticulously show every class attribute, operation, or association on a design diagram. I weave in non-UML symbology as I see fit and I show only those elements I deem important for creating a shared understanding between myself and other interested parties. After all, some low level attributes/operations/classes/associations will “go away” as my learning unfolds and others will “emerge” during coding anyway, so why waste the time?

Notice the “revision number” in the lower right hand corner of the above class diagram. It hints that I continuously keep the diagram in sync with the code as I write it. In fact, I keep the applicable diagram(s) open right next to my code editor as I hack away. As a PAYGO practitioner, I bounce back and forth between code & UML artifacts whenever I want to.

The UML sequence diagram below depicts a visualization of the participatory role of the TxTimeline object in a larger system context comprised of  other peer objects within the scheduler. For fear of unethically disclosing intellectual property, I’m not gonna walk through a textual explanation of the operational behavior of the scheduler component as “a whole“. The purpose of presenting the sequence diagram is simply to show you a real case example that “one diagram is not enough” for me to capture the design of any software component containing a substantial amount of “essential complexity“. As a matter of fact, at this current moment in time, I have generated a set of 7+ leveled and balanced class/sequence/activity diagrams to steer my coding effort. I always start coding/testing with class skeletons and I iteratively add muscles/tendons/ligaments/organs to the Frankensteinian beast over time.

Scheduler UML SD

In this post, I opened up my trench coat and showed you my…  attempted to share with you an intimate glimpse into the way I personally design & develop software. In my process, the design is not done “all upfront“, but a purely subjective mix of mostly high and low level details is indeed created upfront. I think of it as “Big Design, But Not All Upfront“.

Despite what some code-centric, design-agnostic, software development processes advocate, in my mind, it’s not just about the code. The code is simply the lowest level, most concrete, model of the solution. The practices of design generation/capture and code slinging/testing in my world are intimately and inextricably coupled. I’m not smart enough to go directly to code from a user story, a one-liner work backlog entry, a whiteboard doodle, or a set of casual, undocumented, face-to-face conversations. In my domain, real-time surveillance radar systems, expressing and capturing a fair amount of formal detail is (rightly) required up front. So, screw you to any and all  NoUML, no-documentation, jihadists who happen to stumble upon this post. 🙂

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.

Irritated

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?

Broken, Not Bent

October 6, 2012 2 comments

It’s one thing to bend” the UML to express a design concept that you don’t know how to express with the language, but it’s another thing to “break” it outright. By “break“, I mean drawing old-school, ad-hoc, single-symbol diagrams that all look alike and passing them off as UML class, deployment, activity, etc, diagrams.

By propagating broken UML diagrams out into the world in a sincere, but fruitless, attempt to establish a shared understanding among team members, the exact opposite can occur – mass confusion and an error prone, friction-filled development effort. Even worse, presenting the ad-hoc quagmire to customers and financiers who have a rudimentary education in object orientation and UML can cause them to question the competence of the presenters and the wisdom of their investment choice.

But hey, there’s nothing to worry about. Nobody understands or cares about the UML anyway. Thus, the ambiguity, inconsistency, and conflicts inherent in the design won’t be exposed (or ever traced-back-to) if schedule and cost disaster strikes.

All models are wrong. Some, however, are useful. – George E. Box

Proprietary Extensions

September 20, 2012 1 comment

When using a tool or technology that implements a universal standard, beware of inadvertently using non-standard extensions that “lock” you into the vendor’s revenue stream.

The graphic below shows a screenshot from Artisan Real-time Studio version 7.2. Even though the tool implements the UML 2.0 standard, notice that there are several “non-UML” diagrams that you can create: “Constraint Diagram“, “General Flow Diagram“, etc. If you choose to create and use these proprietary extensions, then you’re sh*t out of luck if you get pissed off at Atego and want to port your model over to a different UML tool vendor with a better and/or less expensive solution. D’oh! I hate when that happens.

I’m not trying to single out Atego here. Every commercial vendor, especially of expensive tools, bakes-in a few proprietary extensions to give them an edge over the competition. The sneakier ones don’t annotate or make obvious which features are proprietary – so beware.

Scrum Cheat Sheet

August 28, 2012 4 comments

While reading Schwaber and Sutherland’s official Scrum Guide, I decided to concoct a graphical UML-heavy cheat sheet of the monstrously famous agile framework.

Scrum Framework Components

System Class Diagram

Scrum Roles

Scrum Events

Scrum Artifacts

%d bloggers like this: