say you want to implement a software tool to accomplish an objective — ordinarily i’d say that’s a silly statement, of course you have an objective! you do have an objective… right? we’ll assume so and save that rabbit hole for another topic.
how do you codify that objective and all the things the software should do? how do you measure its success/failure? how do you define its interaction and shared data? how do you want your people to use it? you could write a series of specifications (requirements, functional, design, etc.) with a lot of prose and pretty visio pictures. you could white-board the crap out what you want and scribble “Do Not Erase” in the corner and hope for the best. you could wire-frame the whole ui and spend hours on skype explaining your vision to the developers. you could do several things really or a combination of everything. what’s best for you and your project depends; a one-size-fits-all approach seldom fulfills.
i worked with a colleague years ago who told me there was no such thing as a “best practice” even though we hear it all the time. “good enough practice”, he said, “that’s really what it is.” i think there is wisdom in that (and another potential topic is born).
i am a fan of modeling. modeling is a notation-based exercise that conveys a great deal of information is a small footprint. models are more than illustrations. they are more than descriptive paragraphs. well created models are accurate and precise, they convey specific definitions about the system, and do so without ambiguity; they are not subjective.
there exist several notation languages. BPMN (Business Process Model and Notation), EPC (event-process chain), IDEF (Integration DEFinition), UML (Unified Modeling Language), and others. i’ve used each of these and prefer the uml overall.
hic sunt dracones: if, during a dinner party, you’ve ever brought up the topics of religion, politics, or how to ease your baby during the teething phase, you’ll get this right away — no one is without an opinion. some folks don’t like the uml (and i have no interest in converting them); some folks think it is a divine gift from above. i’m somewhere in between.
the uml is really and object-oriented design construct that has been expanded over the years in such a way that it also performs well for non-software applications. sidebar…
a business system (or sometimes just, system) is made up of people, processes, and technology. process or technology alone doesn’t do the job. people need procedures and controls (rules, policies, guidelines, etc.). when people, process, and technology are standardized (preferably optimized) they comprise a system. every system, as well as its sub-components, has an ICOM (inputs, controls, outputs, and mechanisms).
the uml does several things exceptionally well…
- strong adherence to a common semantic – you like to-may-toes and i like to-mah-toes. calling the whole thing off is not an option so let’s set a standard of what we’re talking about.
- stereotypes, attributes and operations – is it a fruit or a vegetable? what color? seeds or seedless? home-grown or store-bought?
- associations and relationships – which one of you ordered the cheeseburger with no onions?
- multiplicity or cardinality – cut him off after two drinks -or- there are 24 hours in a day (actually, there are between 23 and 25).
- static and dynamic representations – is it a p&l statement or a balance sheet?
- forward engineering – this looks good, where do we go from here?
uml has its challenges and downsides do exist. the challenge i encounter most frequently is two-pronged: inertia and intimidation. stakeholders and sponsors are often resistant to change; they have always used a documented specification approach (everyone has MS Word and Excel) so why introduce something new that they’ll have to learn? uml artifacts pack-in a ton of information and IBS (irritable brain syndrome) has been known to occur. inertia and intimidation, one feeds the other until it spirals at F5 speeds into a real impediment.
the uml conveys a system through artifacts. each artifact is a model diagram and usually supported by some descriptive text. uml artifacts are categorized into discrete groupings…
- organizational artifacts – packages and subsystems
- static artifacts [considered structure diagrams] – use-case model, class model, component model, etc.
- dynamic artifacts [considered behavior diagrams] – sequence diagrams, activity diagrams, state (aka state-machine) diagrams, collaboration models
defining a system with one artifact alone is an invitation for failure. remember the old cartoon drawing of a tire swing?… as proposed by the sponsor… as designed by the developers… as installed at the site… just what the customer wanted. had i modeled that with the uml, i would have used all of the artifact groups above; there would have been no surprises in the end. when i create a model, i do so with three verifiable, testable, and measurable constraints: accuracy, precision, and ambiguity. the first two must be high and the third must be low.
i have several models from my past, and i would like to put some here, but most are proprietary to the extent that i cannot share. i’ll try to review and see which ones won’t get me into trouble. in the meantime, checkout some of these links for further reading. when you’re done, go grab the official specifications, find a good tool that you like, and mean what you say/say what you mean.
- Perdita Stevens, University of Edinburgh, has a great intro — http://homepages.inf.ed.ac.uk/perdita/OO/uml.pdf
- Allen Holub has a terrific reference for uml — http://www.holub.com/goodies/uml/
- imho, the best tool for modeling anything is enterprise architect — http://www.sparxsystems.com/