LavaBlast Software Blog

Help your franchise business get to the next level.
AddThis Feed Button

jUCMNav Tutorial 5: Dynamic Stubs

clock February 21, 2010 07:40 by author JKealey


This is the last jUCMNav tutorial in a series of five. Below are links to other articles in this series.


The above video models a simple process for a paintball location. Customers sign a waiver (limitation of liability), pay, and have fun. 

  • Creating dynamic stubs
  • Dynamically selecting which plug-in map will be selected by a scenario


jUCMNav Tutorial 4: Waiting places and timers

clock February 19, 2010 00:39 by author JKealey


This is the fourth jUCMNav tutorial in a series of five. Below are links to other articles in this series.


The above video models a simple process for a paintball location. Customers sign a waiver (limitation of liability), pay, and have fun. 

  • Introduce waiting places, timers, timeout paths
  • Introduce start point pre-conditions
  • Create a scenario with multiple start points
  • Create a path that triggers a blocked path


jUCMNav Tutorial 3: Loop and scenario enhancements

clock February 18, 2010 00:38 by author JKealey


This is the third jUCMNav tutorial in a series of five. Below are links to other articles in this series.


The above video models a simple process for a paintball location. Customers sign a waiver (limitation of liability), pay, and have fun. 

  • Including a scenario definition inside another
  • Creating an Integer variable 
  • Writing pseudo-code inside responsibilities
  • Creating a loop


jUCMNav Tutorial 2: Adding forks & joins

clock February 17, 2010 07:37 by author JKealey


This is the second jUCMNav tutorial in a series of five. Below are links to other articles in this series.


The above video models a simple process for a paintball location. Customers sign a waiver (limitation of liability), pay, and have fun. 

  • Creating an or-fork and or-join to model an exclusive choice
  • Creating an and-fork and and-join to model concurrency
  • Merging a start point and an end point
  • Creating a Boolean variable
  • Initializing variables inside a scenario


jUCMNav Tutorial 1: Creating a simple path

clock February 16, 2010 07:46 by author JKealey


This is the first jUCMNav tutorial in a series of five. Below are links to other articles in this series.


The above video models a simple process for a paintball location. Customers sign a waiver (limitation of liability), pay, and have fun. 

  • How to create a blank Use Case Map
  • Using the Path Tool to create a path
  • Presents the following path nodes: Start Point, End Point, Empty Point, Responsibility, and Static Stub.
  • Presents the “Refactor into Stub” menu option
  • Presents Components and how to change their fill color.
  • Explains how to bind path nodes to components.
  • Create a simple scenario


Software engineers as salespeople

clock February 15, 2010 10:12 by author JKealey

LavaBlast is a small startup; we don’t currently have dedicated salespeople. I still do most of the selling at this point – I’ve got a background in software engineering, not sales. That may seem crazy until you realize that we don’t sell commercial-off-the-shelf software. If a prospect needs us to build custom software on top of our existing platform, the engineering team is involved in determining the scope (and therefore the cost presented in the quote). Because of the scope of the systems that we’re building, we have the “luxury” to spend more time on each individual quote and learning more about the prospect’s business. Adding a personalized touch in every quote gives us a competitive advantage compared to firms that pump out boilerplate text without analyzing the context.  I strongly feel that, for this type of sale, understanding the customer’s problems is much more important than having them understand your product. Furthermore, understanding/solving problems is definitely something software developers know how to do!

LavaBlast Software builds integrated software solutions for the franchise industry. Although the systems we build are similar because we reuse the building blocks which we’ve developed over the years, we understand that each franchise has different business rules. Understanding these rules before building custom software is of capital importance. This assertion holds regardless of what kind of software you’re building: everyone on the team should have a clear understanding of what needs to be built. Otherwise, you build software that only partially matches your user’s expectations and you need to go back to the drawing board to correct it.

Don’t get us wrong; we’re not fans of the Big Design Up Front (BDUF) approaches such as the waterfall software development model. We follow a more agile development methodology but there is one thing we do with each and every new franchisor client that approaches us: we model their business processes using a visual notation called the Use Case Map notation, a subset of the User Requirements Notation. This helps us understand their business and what they need built. We’ll come back to this notation in a minute.

Communicating business processes

Most business processes are simple (and should be), but a few are not as straightforward. Imagine an online store that sells quilts: the customer goes to the online store, chooses a quilt or two, provides payment, and the warehouse ships them. Simple enough? Add a few requirements to make it complex:

  • a customer can put a particular quilt (a unique hand-made design) on hold and provide payment for it within a week
  • customers can visit the warehouse and make purchases directly – it takes 24 hours for the website to be notified of stock changes
  • the store also receives telephone/fax orders
  • a customer can return a quilt for a full refund with 15 days, in person or by mail.
    These few extra requirements make the whole process a bit more complex.  In real life, there are always dozens of these added constraints. Some are very infrequent whereas others cause problems on a daily basis. Some can be solved by a better process while others can only be mitigated (especially things like delayed notifications) – you need to understand the context to be able to represent the current process and differentiate it from what you see as the ideal process to be implemented. However, as you are the developer and not the domain expert, you need to effectively communicate with the other stakeholders in order to create the best system. In most cases, your best guess is not sufficient.
    We’ve found that the best way to communicate these processes with our customers, who are not in the software world, is by using the User Requirements Notation. The notation provides a way to visually represent processes very quickly. Spending a few minutes designing a Use Case Map is akin to drawing on a whiteboard, with the added benefit of being a persisted artefact that can be “executed” to visualize certain scenarios. Additionally, the Goal-Oriented Requirements Language (the other half of the User Requirements Notation) allows the designer to compare different processes in terms of non-functional requirements such as performance, maintainability, security, etc.

Better than drawing on a whiteboard

Back in 2007, we’ve talked about the Use Case Map notation and jUCMNav in our initial blog post. To celebrate the release of jUCMNav version 4.2.0, we thought it would be nice to produce a series of tutorials that show you how to create your own model using jUCMNav. In case you didn’t know, LavaBlast’s co-founders have contributed massively to jUCMNav in the past five years. We’re responsible for 60% of the code in this open source project which we started during our time as undergraduate software engineering students at the University of Ottawa.

The following is a short 90 second video that gives you an example model and a very quick overview of what can be done with the notation and the tool. Stay tuned to our next blog posts to see us build this example from the ground up. The overview and the tutorial are intended for people with a background in software development. If you wish to introduce the notation to someone outside the development community, I would recommend starting with simple screenshots instead of showing the tool (which, in the end, should only be used by developers).


We hope you found this introduction interesting and that you’ll not only watch our upcoming tutorials but also download jUCMNav (an Eclipse plug-in) and play with it!

How Super Mario Bros Made Me a Better Software Engineer

clock February 28, 2008 00:07 by author JKealey

Super Mario Bros.Over the past month, I've been working hard on our business plan's second iteration. We've accomplished a lot in our first year and things look very promising for the future.  Writing a business plan helps an entrepreneur flesh out various concepts, including one's core competency and niche market. We illustrate in great detail what makes LavaBlast such a great software company for franchisors and the process of writing it down made me wonder about what made improved my software engineering talents, personally. Luckily for you, this post is not about me personally but rather an element of my childhood that impacted my career.

I don't recall exactly how old I was when I received an 8-bit Nintendo Entertainment System (NES) for Christmas, but I do remember playing it compulsively (balanced with sports like baseball, soccer and hockey!). The first game I owned was Super Mario Bros but I later obtained its successors to augment my (fairly small) cartridge collection. For the uninitiated, the NES does not incorporate any functionality to allowing saving the player's progress. Countless hours were spent playing and replaying the same levels, allowing me to progress to the end of the game and defeating my arch-nemesis, Bowser.

I enjoyed the time during which I played video games and it irritates me to hear people complaining about how video games will convert their children into violent sore-loser bums. In any case, I'd rather focus on the positive aspects of playing Super Mario Bros and other video games during my childhood. Just like mathematics develops critical thinking and problem solving skills, I strongly believe these video games influenced my personality to a point where they are probably defined my career. Disclaimer: I don't play video games that much anymore, but over the last year, I did purchase a Nintendo Wii and Nintendo DS Lite because I love the technology and the company's vision.

Quality #1: Persistence

Some people say I am a patient person, but I would beg to differ. I have trouble standing still intellectually, and although it is a strength in my industry, it isn't the best personality trait :) However, I am VERY persistent. I will attempt solving a problem over and over until I find a solution. Although I don't experience many painful programming situations on a daily basis, I very rarely give up on any programming problems. If I can't solve the problem immediately, it will keep nagging at me until I find a solution. A direct parallel can be traced with playing the Super Mario Bros series where the whole game had to be played over and over again to make any progress. (Anyone else remember trying to jumper over a certain gap in the floor in the Teenage Mutant Ninja Turtles NES game only to fall in the gap and have to climb back up again?) The games helped me train my persistence, a tool which any entrepreneur must use every day.

Quality #2: Pattern Recognition

Software engineering is all about pattern recognition. Refactoring the code to increase reuse, extracting behavioural patterns inside the strategy design pattern, creating object inheritance trees, or writing efficient algorithms based on observed patterns. I feel pattern recognition is one of my strengths, since I can easily see commonalities between seemingly different software problems. I believe this skill was refined by playing various video games, because the the player must observe the enemy's behaviour in order to succeed. In some games, agility doesn't really matter: it's all about knowing the pattern required to defeat the enemy (to the point where it sometimes become frustrating!). The most challenging parts of video games is when the game deliberately trains you to believe you'll be able to stomp an enemy by using a particular technique but, to your surprise, the technique fails miserably. You need to adapt to your environment, and think outside the box.

Quality #3: Creativity

Mathematicians and software engineers are creative thinkers, more than the uninitiated might think. I see software as a form of art, because of its numerous qualities that are hard to quantify. Software creators are artists in the sense that regardless of their level of experience, some will manage to hit the high notes while others could try their whole lifetime without attaining the perfect balance of usability, functionality, performance, and maintainability. Playing a wide breadth of video game styles lets you attack different situations with a greater baggage. I'm not totally sure how putting Sims in a pool and removing the ladder or shooting down hookers in Grand Theft Auto helped me in my day-to-day life, but it was still very entertaining :) The upcoming Spore game is very appealing to me because it combines creativity with pattern recognition, thanks to generative programming.  If you haven't heard about this game, I recommend you check it out immediately!

Quality #4: Speedy reactions

For Chris Brandsma: "IM N YUR BOX, WIF MAH WIFE" At LavaBlast, such as in many other software startups, it is critically important that all developers be fast thinkers. Indeed, when your core expertise is production, as opposed to research and development, you need to be able to make wise decisions in a short period of time. Personally, I can adapt to the setting (research environment versus startup environment) but my strength is speedy problem solving and I consider myself a software "cowboy". By combining my knowledge of of how to right reusable and maintainable code with my good judgement of what battles are worth fighting, I can quickly come up with appropriate solutions, given the context. In video games, the player needs to react quickly to avoid incoming obstacles while staying on the offensive to win the game. Of course, the mental challenges we face in our day-to-day lives of developing software is much more complex than what we encounter playing video games (which trains physical reaction time), but there is still a correlation between the two tasks.

Quality #5: Thoroughness

What differentiates a good software engineer from a plain vanilla software developer is their concern for quality software, across the board. Software quality is attained the combined impact of numerous strategies, but testing software as you write it, or after you change it, is critical. For the uninitiated, a popular methodology is to test BEFORE you write code. In any case, this talent can also be developed by video games such as the classic Super Mario World (SNES) where the player tries to complete all 96 goals (72 levels) by finding secret exits. Reaching thoroughness requires the player to think outside the typical path (from left to right) and look around for any secret locations (above the ceiling). Finding secret exits is akin to achieving better code coverage by trying atypical scenarios. 

Quality #6: Balance

Playing Super Mario Bros as a child helped me develop a certain sense of balance between my various responsibilities (school) and entertainment activities (sports, games, social activities). If you're spending 16 hours a day playing World of Warcraft or performing sexual favors in exchange for WoW money, your mother is right to think that you have a problem. Launching a software startup is a stressful experience, and it helps to be able to wind down with a beer and a soothing video game. A quick 20min run on a simple game before bed can work wonders! Of course, it is no replacement for sports or social activities, but it sure beats dreaming about design patterns.

What's missing? 

Super Mario Galaxy In my opinion, there are two major qualifies that video games don't impact. Having these two qualities is a requirement to becoming a good software engineer. First, video games do not help you interpret other people's needs. Second, video games do not help you communicate efficiently. What does? Experience, Experience, Experience. Being able to deal with people on a daily basis is mandatory, and the video games I played as a child did not help. However, this statement may no longer be true! Today, many massively multiplayer online games require good collaboration  and organizational skills. Furthermore, the new generation of gaming consoles are using the Internet to allow people to play together. 

Furthermore, I find games like the new Super Mario Galaxy (Wii) very interesting for future mechanical engineers. Indeed, the game presents a three-dimensional environment in an novel way, training the brain to think differently about three-dimensional space. You have to play the game to understand, but because the camera is not always showing Mario in the same angle, you have to get a feeling of the environment even if you don't see it (you're on the opposite side of a planet) or are upside down on the southern hemisphere. I can imagine children and teenagers playing the game today will have greater facility to imagine an object from various perspectives, while in studying physics or mechanical engineering in university.

In conclusion, I admit my whole argument can be invalided by saying that I played these types of games because I was inherently inclined to the software engineering profession, but the commonalities are still interesting to review! What are your thoughts on the subject? What do you think drove you to this profession (or drove you away)?

Legal Disclaimer: Did you know that the usage of the title of "software engineer" is much more regulated in Canada than it is in the United States? Although I detain a bachelor's degree in software engineering, and a master's degree in computer science which focused on requirements engineering, I can currently only claim the title of "junior engineer", as I recently joined the professional order.

Follow up: powerrush on DotNetKicks informed me that I'm not the only one who feels games influence software engineers

kick it on

Month List


The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2017

Sign in