UML in practice – my top fives

I recently came across an interesting publication regarding the adoption and practices of Unified Modeling Language (UML) in the real world. Written by Marian Petre and presented in ICSE’13, titled “UML in practice”. The article stated that,

UML has been described by some as “the lingua franca of software engineering”. Evidence from industry does not necessarily support such endorsements. How exactly is UML being used in industry — if it is? This paper presents a corpus of interviews with 50 professional software engineers in 50 companies and identifies 5 patterns of UML use.

For those that are impartial to reading blog posts, obviously ;), here is great summary of the aforementioned paper from a blog that I follow.

There are two noteworthy takeaways.

  1. After 20 years, UML is not widely adopted due to its complexity and overhead, difficulties in synchronising code and design, and lack of context (UML often deals with architecture and not the whole system)
  2. When UML are used, only parts of the diagram notation are adopted; class, sequence, activity, state and use case diagrams. These diagrams have the lowest barrier of entry and provides a very useful and flexible tool for communicating particular view of a system.

For me personally, I too fall under the “selective usage” category. I also believe that the informal nature of UML, particularly when juxtaposed with other formal methods, showcases that UML is great for illustrating overarching architectural breakdown but horrible for specifying detailed implementations.

My experience with UML is a very positive one. Here are my top five tips for some UML hackery:

When I use UML, I…

  • follow a particular design methodology, one such as Concurrent Object Modeling and architectural design mEThod (COMET). Doing so will lead to selectively subsetting the notations and diagrams, at the same time applying structure and guidelines for illustrating design and context for the system in question.
  • focus on the diagrams that can be easily understood by stakeholders. No point building a state machine that captures non-determinisms and lambda transitions when no stakeholders cares about it. Do, however, provide useful class breakdowns or entity relations if people finds them useful.
  • formalise the models depending on the system in question. For example, adding Object Constraint Language (OCL) into your requirement models makes it formal. It can be audited and proven. Formalising UML is suitable for AS 61508 classified systems, compliant to certain Safety Integrity Level (SIL) levels.
  • estimation the size of project via use case estimations. This is a great baseline for sanity checks.
  • use a good Computer-aided software engineering (CASE) tool. See the following CASE tool comparisons as an example;

Spend some time and get to know this visual language. You will find a clever and flexible way to communicate your ideas and intent to a wider audience and with improved precision and articulation.

I’m calling it! Is design synthesis or requirement automation a reality today?

After devoting my post graduate years in automated design synthesis, at times I feel the need to evaluate the relevance of my work against modern tool chains and trends. Automated design synthesis aligns with *DD frameworks and I feel, with tool chains supporting continuous integration, that automated design synthesis may now actually be a reality. A form of requirement automation if you will.

The core principle behind DDD, TDD, BDD and ATDD is about writing code that aims to deliver implementation for requirements. The mapping is 1 to 1 and it is often an iterative process. In order to illustrate that the code correctly behaves as designed, artifacts are produced to directly support testability and serves to illustrate conditions of satisfaction.

Peeling off yet another layer, all *DD principles focus on encapsulating requirements using regular language, then forming individual requirement pieces into regular expressions. Regular expressions are equivalent to deterministic finite automata (DFA) and therefore can be combined with other DFA via Kleene’s theorem. This is the crux of design synthesis and code generation.

I surmise that it is now possible to perform requirement automation iteratively, from synthesising verifiable design artifacts, to executable test cases, to rapidly deploying these new implementation into production environment that are ready to be acceptance tested and released with moments noticed.

I hope to further examine this notion in the coming blog posts in order to fully explore the possibility of delivering requirement automation.


Building on varnish-agent2

The varnish-agent2 existing code base is pretty solid,  rather beautiful I might add. These simple words, keep it simple, has been realised by the following rule of thumb.

– Close to 0 configuration
– “Just works”
– Maintainable
– Generic
– Stateless

For those that are keen to get started on the varnish-agent2 code base, I hope that this document will be of some use. I have used a tiny subset of the Concurrent Object Modeling and architectural design mEThod (COMET), particularly the Requirements Modeling, Analysis Modeling and snippets of the actual Design Model.

Lastly, this document mostly serves as a mental note for myself 🙂

Requirements Modeling

The requirement for the vagent2 is to provide an extendible restful interface for varnish cache. In addition, vagent2 act as the point of integration for varnish cache with other systems – e.g. an administrative or monitoring system.

The use cases are simple right now, and is depicted in the use case diagram below.

vagent2 use cases

vagent2 use cases

Analysis Modeling

vagent2 is designed to support the full spectrum of HTTP method types. A user of the vagent2 will issue these HTTP requests and receive JSON data as response where applicable. Furthermore, the vagent2 is built with modules in mind to address a potentially expanding feature set. Lastly, each modules should be able to communicate and reused by another module.

IPC lies at the heart of the varnish-agent2 code base and message passing is the norm here for implementing an event driven model. Each module follows vagent2’s plugin paradigm, and comes equipped with the module’s own private data set. The plugin therefore follows the IPC set of callback methods, such as ipc_start and ipc_run. These methods are assigned to the appropriate functions within each module.

For the module to be exposed as a restful interface, a simple httpd_register method will hook in the module’s reply method of choice, and expose it appropriately.

For any module, the basic dependencies is depicted below.

Module breakdown

basic module dependencies

Static Modeling

varnish-agent2 ships with a few core modules, such as the logger, shmlog access, httpd and ipc modules. vstatus and vadmin provides access to the shmlog via Varnish API. Note that as of writing this blog, varnish 3.0.3 was used.

These aforementioned modules provide the building blocks for managing varnish cache. For an overview of the static models, see the class diagram below.

Static Model

Static overview of vagent2

Dynamic Modeling

The process of initialising a module is rather straightforward. First, add a new init method for the new module in plugins.h, ensure that you have called the init method in main.c, and of course, allocated some memory for the new plugin in main.c too.

This new module must provide an implementation of the new init method. See diagram below depicting vban’s initialisation process.

vban initialisation process

vban initialisation process

Once initialised, by hooking onto struct agent_plugin* structure, the new module will correspond to the IPC life cycle.

plugin->start  = ipc_start;
plugin->ipc->priv = your_private_plugin_data;
plugin->ipc->cb = your_plugin_callback;

plugin->start is called when your plugin starts. Note that you need to assign a start method if you want the IPC to execute your callback.

plug->ipc->priv refers to a persisted data for your plugin. This can be anything, and as a rule of thumb, this is a good place to hold references to other modules.

plug->ipc-cb refers to the callback method of when ipc_run is issued by another module.

A sample execution path

To tie it all together, the collaboration diagram below illustrate the execution path of issuing a ban to the vagent2. Note that ipc is used to reach the vadmin module.

Issue a ban

Issue a ban

UML CASE Tools for the Mac

Unified Modeling Language (UML) is a visual language for communicating software design, architectures, workflows etc.

Traditionally commercial Computer-aided software engineering (CASE) tools are abundant on the Windows platforms, with ArgoUML being the only open source UML tool back in day.

There are three categories of CASE tools. First up is the a graphical tool with stencils supporting UML syntax, a glorified Microsoft Paint if you will. The second is the traditional CASE tool with reverse engineering, round-trip development and team collaboration. Last but not least, CASE tools in the clouds. These are hosted UML tools for drawing and often have integration with wikis.

Selection criteria

The criteria for me for a CASE tool for the Mac are as follow:

  • Suitable for start up company, small team
  • Agile and fast learning curve
  • A desktop application
  • Simple to use
  • Includes the basic diagrams
  • Uses UML standards, not stencils
  • No need to use Wine, Cross-over, Parallel or VMware to run the tool

If I used Windows…

My CASE tool of choice traditionally is Enterprise Architect by Sparx System. It matches most of the criteria with added flexibility catering for larger teams, with model check-in and check-out, feature matrices, linking features to requirements to implementation and even to sprints. It is both an excellent Scrum tool and project management tool for large enterprise teams. The only downside to Enterprise Architect is that it runs in Windows and requires virtualisation to run on the Mac.

CASE tools summarised

Mac CASE tools I have tested out are Visual-Paradigm, Poseidon for UML, ArgoUML, Omnigraffle, and Astah community edition.

Visual-Paradigm, as the name suggests, is quite big on the visuals. It is a solid UML tool supporting wide variety of diagrams outside of UML. For example, Mindmap is supported by Visual-Paradigm.

Poseidon for UML is traditionally built on ArgoUML, the open-source UML project. It is clean, well supported, simple and quick to use. It follows the UML standards to its fullest and thus your models can be exported out to another tool such as Rational Rose or Enterprise.

ArgoUML is an open source UML project. It is also relatively simple to get going and it maintains the classic Java Swing look and feel.

Omnigraffle is similar to Visio – a graphical tool for drawing. UML is supported as stencils.

Astah is another UML tool, simple to get going and can be upgraded to a business edition for added features such as collaboration.

For a cloud-based solution, Gliffy is pretty decent. It came with our Atlassian OnDemand setup and it works beautifully with Confluence. A special mention to for providing such a cool idea.

And the winner is….

So which one to choose? For us, a start up company with small teams, I have chosen Astah community edition for its simplicity and cost with Poseidon coming in close second. Astah is fast and easy to get going. It can be extended to suit team collaboration if needed. If we ever become the next Google, I will consider Enterprise Architect again and live with VMware running Windows XP.