Archive
Unconstraining UML And SysML Modeling Tools
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.
Priority List
In his brilliant and elegant essay, “Capitalism is Dead. Long Live Capitalism“, Gary Hamel laments about the deterioration of capitalism into those other bad, highly inequitable, anti-American “isms”. He says:
So why do fewer than four out of ten consumers in the developed world believe that large corporations make a “somewhat” or “generally” positive contribution to society? Why is it that only 19% of Americans tell pollsters they have “quite a lot” or a “great deal” of confidence in big business?
In Gary’s opinion, the reason is……
… the unwillingness of executives to confront the changing expectations of their stakeholders. In recent years, consumers and citizens have become increasingly disgruntled with the implicit contract that governs the rights and obligations of society’s most powerful economic actors—large corporations. To many, the bargain seems one-sided—it’s worked well for CEOs and shareholders, but not so well for everyone else.
This lead-in dovetails into the idea of a “CEO stakeholder priority list“. The UML class diagram below shows six types of corpo stakeholders. Of course, the six types were arbitrarily picked by me and there may be others on the same level of abstraction that you think are missing. Notice that the “earth” is a passive stakeholder that can’t directly and instantaneously exert pressure on the way corpricracies behave; unlike the other people-type stakeholders.
Now, check out some sample CEO stakeholder priority lists below. With 6 stakeholders types, the number of unique lists is quite a lot: 6! = 6 x 5 x 4 x 3 x 2 = 720. I just semi-randomly concocted these three specific sample lists so that I can continue babbling on while hoping that you’re still reading my drivel.
My own unscholarly opinion is that the vast majority of CEOs, their appointed-yes-men VP teams, and their hand picked boards of directors either consciously or unconsciously operate according to the blue list (or any other instance that prioritizes the “executives” stakeholder first). My opinion aligns with Mr. Hamel’s assertion that too many corpo captains are making decisions that materially favor themselves (first) and their shareholders while disproportionately harming the other stakeholder types.
But wait, hasn’t this always been the case with capitalism? If so, why has it suddenly become fashionable for dweebs like me to vilify corpricracies that operate in accordance with the blue list?
In closing, I feel the need to repeat the best quote in Hamel’s blarticle:
There are CEOs who still cling to the belief that a company is first and foremost an economic entity rather than a social one. – Gary Hamel
To those CEOs who still think that the word “social” equates to communism, get over it and move into this century.
Accessing Configuration Data
Assume that on initialization, your C++ application reads in a bunch of configuration parameters from secondary storage prior to commencing its runtime mission. Via a trio of simple UML class diagrams, the figure below shows three ways (patterns?) to structure your application to read in and store configuration data for subsequent use by the program‘s productive, value added classes (user1, user2, etc).
In the first design, a singleton class is used to read and store the runtime configuration in RAM. The singleton can either be auto-instantiated at program load time in global/namespace memory before main() executes, or the first time it is accessed by one of the program’s user objects.
In the second approach, you employ a “ConfigOwner” class that encapsulates and owns the configuration data reader class (AppConfig). On program startup, the “ConfigOwner” object instantiates the “AppConfig” reader object and then subsequently passes a reference/pointer to it to all the user objects (which the “ConfigOwner” object doesn’t own).
In the third strategy, a higher level object (AppEncapsulator) owns all other objects in the application. On startup, this parent class is instantiated first. It fully controls the initialization sequence, creating the “AppConfig” object first and then pushing a reference/pointer to it down to its child User class objects when it subsequently constructs them.
Since the application startup sequence is centrally controlled, the third, parent-child approach is totally thread-safe. The implementation of the singleton approach, where the singleton is instantiated at program load time before main() starts executing, is also thread safe. The instantiation-on-first-access singleton approach and the ConfigOwner approach are subtlely thread unsafe without some clever synchronization coding added to ensure that the AppConfig object is fully constructed before it is accessed by its users.
Since I’m not fond of using singletons in situations where they’re not absolutely required (and this is arguably one of those cases, no?) and I disdain “clever” coding, I prefer the last, centrally controlled strategy. How about you? Are you clever, or a simpleton like me?
Note: Don’t mind the bracket turd on the right of the diagram. Since I’m a lazy ass and I try not to be a perfectionist when perfection is not needed, I left the pooper in rather than removing, fixing, and reinserting the graphic into the post. Too much work.
To Call, Or To Be Called. THAT Is The Question.
Except for GUIs, I prefer not to use frameworks for application software development. I simply don’t like to be the controllee. I like to be the controller; to be on top so to speak. I don’t like to be called; I’d rather call.
The UML figure below shows a simple class diagram and sequence diagram pair that illustrate how a typical framework and an application interact. On initialization, your code has to install a bunch of CallBack (CB) functions or objects into the framework. After initialization, your code then waits to be called by the framework with information on Events (E) that you’re interested in processing. You’re code is subservient to the Framework Gods.
After object oriented inheritance and programming by difference, frameworks were supposed to be the next silver bullet in software reuse. Well crafted, niche-based frameworks have their place of course, but they’re not the rage they once were in the 90s. A problem with frameworks, especially homegrown ones, is that in order to be all things to all people, they are often bloated beyond recognition and require steep learning curves. They also often place too much constraint on application developers while at the same time not providing necessary low level functionality that the application developer ends up having to write him/herself. Finding out what you can and can’t do under the “inverted control” structure of a framework is often an exercise in frustration. On the other hand, a framework imposes order and consistency across the set of applications written to conform to it’s operating rules; a boon to keeping maintenance costs down.
The alternative to a framework is a set of interrelated, but not too closely coupled, application domain libraries that the programmer (that’s you and me) can choose from. The UML class and sequence diagram pair below shows how application code interacts with a set of needed and wanted support libraries. Notice who’s on top.
How about you? Do you like to be on top? What has been your experience working with non-GUI application frameworks? How about system-wide frameworks like CORBA or J2EE?
Extended Business Model
In Zappos.com CEO Tony Hsieh’s new book: “Delivering Happiness“, Tony describes the original Zappos.com business model as “drop-ship”. As the UML sequence diagram below shows, a customer would place an order at the Zappos.com website, Zappos would relay the order directly to the shoe manufacturer’s warehouse, and the order would be fulfilled and shipped directly from ground zero. It was a low cost model for Zappos, but it limited sales growth since many shoe manufacturers didn’t have the information systems in place to execute their end of the model. In addition, sales were limited to the inventory that warehouses held in storage, not necessarily what Zappos’ customers wanted.
During the initial stage of growth, Zappos.com was often short on cash (surprise!) and often just a month or two away from goin’ kaput (surprise, again!). The Zapponians needed to increase sales in order to increase cash flow. During a brainstorming session in a local bar (not in a committee of BMs, CCRATS, BOOGLs, consultants, and other self-important dudes) they came up with the idea of extending their existing business model.
Man creates by projection, nature creates by extension – Unknown
The sequence diagram below shows the extended business model that Tony “chez” et al decided to move toward. In a nutshell, Zappos would purchase or lease a warehouse and stock its own inventory based on trend information extracted from its website. As simple as it looks, the devil is in the details. Buy and read the book to learn how they pulled it off – despite being cash poor and close to going tits-up.
If changing our business model is what’s going to save us, then we need to embrace and drive change. – Tony Hsieh
How many times have you heard or spoken the “embrace change” words above but never experienced or executed any follow through?
A Blessing And A Curse
The figure below depicts a UML class diagram model of the static structure of a typical Wiki system. A Wiki may be comprised of many personally controlled and/or global workspaces. Each logical workspace is composed of user created work pages and news items (a.k.a. blog posts). Lastly, a Wiki contains many user accounts that are either created by the users themselves or, in a more controlled environment, created by a gatekeeper system administrator. Without an account, a user cannot contribute content to the Wiki database.
Org Wikis are both a blessing and a curse. They’re a blessing for the DICforce in that they allow for close collaboration and rapid, real-time information exchange between and across teams. They also serve as an easily searchable and publicly visible record of org history.
In malevolent and stovepiped CCHs where SCOLs and BOOGLs rarely communicate horizontally and, even more rarely, downward to the DICforce, Wikis are a curse because….
Networks make organizational culture and politics explicit. – Michael Schrage
BOOGLs and SCOLs that preside over malevolent CCHs don’t like having their day-to-day operational behavior exposed to the light of day. If a malevolent CCH org is liberal enough to “approve” of Wiki usage, chances are that none of the BOOGLs or SCOLs will contribute to its content. In the worse case, a Wiki police force may be established to enforce posting rules designed to keep politics and positioning behavior secret. Hell, without censorship, the DICforce might form the opinion that they are being led by a gang of thugs who are out for themselves instead of the lasting well being of the org.
Are you here to build a career or to build an organization? – Peter Block
A Change In Funding Source
The figure below shows a dorkily simplistic UML sequence diagram example of the provision of service from a support group (e.g. purchasing, quality assurance, configuration management) to a product development group within a CCH patriarchy. During product development, the team aperiodically requires and requests help from one or more corpo groups who’s raison d’etre is to provide timely support to those who need it. 
Depending on who’s leading the support group, the service it provides can be highly responsive and of high quality. However, since the standard “system” setup in all CCH corpocracies is as shown in the sequence diagram below, the likelihood of that being true is low. That’s because in centralized patriarchies, all budgets, salaries, and token rewards are doled out by the sugar daddys perched at the top of the pyramid. On the way down, the middlemen in the path take a cut out of the booty for, uh, the added-value “leadership” they provide to those on the next lower rung in the ladder.
In exchange for their yearly/quarterly investments in the lower layers of the caste system, the dudes in the penthouse require periodic status reports (which they can’t understand and which are usually cleverly disguised camouflage) that show progress toward wealth creation from the DICs below.
Since their bread is buttered from the top and not their direct customers, the natural tendency of support groups is to blow off their customers’ needs and concentrate on maximizing their compensation from the top. They do this, either consciously or unconsciously, by adding complexity to the system in the form of Byzantinian procedural labyrinths for customers to follow to show how indispensable they are to the b’ness. As a result, their responsiveness decreases and their customers experience an increase in frustration from shoddily late service.
So how does one fix the standard, dysfunctional, centralized, CCH setup? Check out and ponder the sequence diagram below for a possible attempt at undoing the dysfunctional mess. Can it work? Why, or why not?
By definition, if everyone is doing industry best practice, it’s not best practice. It’s average practice.
Exaggerated And Distorted
The figure below provides a UML class diagram (“class” is such an appropriate word for this blarticle) model of the Manager-Developer relationship in most software development orgs around the globe. The model is so ubiquitous that you can replace the “Developer” class with a more generic “Knowledge Worker” class. Only the Code(), Test(), and Integrate() behaviors in the “Developer” class need to be modified for increased global applicability.
Everyone knows that this current model of developing software leads to schedule and cost overruns. The bigger the project, the bigger the overruns. D’oh!
In this article and this interview, Watts Humphrey trumps up his Team Software Process (TSP) as the cure for the disease. The figure below depicts an exaggerated and distorted model of the manger-developer relationship in Watts’s TSP. Of course, it’s an exaggerated and distorted view because it sprang forth from my twisted and tortured mind. Watts says, and I wholeheartedly agree (I really do!), that the only way to fix the dysfunction bred by the current way of doing things is to push the management activities out of the Manager class and down into the Developer class (can you say “empowerment”, sic?). But wait. What’s wrong with this picture? Is it so distorted and exaggerated that there’s not one grain of truth in it? Decide for yourself.
Even if my model is “corrected” by Watts himself so that the Manager class actually adds value to the revolutionary TSP-based system, do you think it’s pragmatically workable in any org structured as a CCH? Besides reallocating the control tasks from Manager to Developer, is there anything that needs to socially change for the new system to have a chance of decreasing schedule and cost overruns (hint: reallocation of stature and respect)? What about the reward and compensation system? Does that need to change (hint: increased workload/responsibility on one side and decreased workload/responsibility on the other)? How many orgs do you know of that aren’t structured as a crystalized CCH?
Strangely (or not?), Watts doesn’t seem to address these social system implications of his TSP. Maybe he does, but I just haven’t seen his explanations.
PAYGO II
PAYGO stands for “Pay As You Go“. It’s the name of the personal process that I use to create or maintain software. There are five operational states in PAYGO:
- Design A Little
- Code A Little
- Test A Little
- Document A Little
- Done For Now
Yes, the fourth state is called “Document A Little“, and it’s a first class citizen in the PAYGO process. Whatever process you use, if some sort of documentation activity is not an integral part of it, then you might be an incomplete and one dimensional engineer, no?
“…documentation is a love letter that you write to your future self.” – Damian Conway
The UML state transition diagram below models the PAYGO states of operation along with the transitions between them. Even though the diagram indicates that the initial entry into the cyclical and iterative PAYGO process lands on the “Design A Little” state of activity, any state can be the point of entry into the process. Once you’re immersed in the process, you don’t kick out into the “Done For Now” state until your first successful product handoff occurs. Here, successful means that the receiver of your work, be it an end user or a tester or another programmer, is happy with the result. How do you know when that is the case? Simply ask the receiver.
Notice the plethora of transition arcs in the diagram (the green ones are intended to annotate feedback learning loops as opposed to sequential forward movements). Any state can transition into any other state and there is no fixed, well defined set of conditions that need to be satisfied before making any state-to-state leap. The process is fully under your control and you freely choose to move from state to state as “God” (for lack of a better word) uses you as an instrument of creation. If clueless STSJ PWCE BMs issue mindless commands from on high like “pens down” and “no more bug fixing, you’re only allowed to write new code“, you fake it as best you can to avoid punishment and you go where your spirit takes you. If you get caught faking it and get fired, then uh….. soothe your conscience by blaming me.
The following quote in “The C++ Programming Language” by mentor-from-afar Bjarne Stroustrup triggered this blog post:
In the early years, there was no C++ paper design; design, documentation, and implementation went on simultaneously. There was no “C++ project” either, or a “C++ design committee.” Throughout, C++ evolved to cope with problems encountered by users and as a result of discussions between my friends, my colleagues, and me. – Bjarne Stroustrup
When I read it on my Nth excursion through the book (you’ve made multiple trips through the BS book too, no?), it occurred to me that my man Bjarne uses PAYGO too.
Say STFU to all the mindlessly mechanistic processes from highly-credentialed and well-intentioned luminaries like Watts Humphrey’s PSP (because he wants to transform you into an accountant) and your mandated committee corpo process group (because the chances are that the dudes who wrote the process manuals haven’t written software in decades) and the TDD know-it-alls. Embrace what you discover is the best personal development process for you; be it PAYGO or whatever personal process the universe compels you to embrace. Out of curiosity, what process do you use?
If you’re interested in a higher level overview of the personal PAYGO process in the context of other development processes, you can check out this previous post: PAYGO I. And thanks for listening.
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
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 