Posts Tagged ‘design’

A Simple and Free UML Tool

July 17, 2011

Now that I have lost my MagicDraw license, I have been looking for a free alternative to do some UML. In looking around I found a great alternative called Violet UML.

I’m a big fan of it mainly because of how simple it is to use. The usability directly attributable to how stripped down it is or at least appears to be. Honestly it looks to have all the functionality that I need, supporting the following diagrams with necessary objects.

  • use-case diagram
  • class diagram
  • activity diagram
  • sequence diagram
  • state diagram
  • object diagram

It doesn’t have a ton of functionality to generate code, create unusual diagrams or objects, or a million menu options to sort through. I completely appreciate those engineers who leverage that extra functionality, there are situations where you sometimes can’t do without it, so if that’s the case then this tool isn’t for you. Extremely good though for just creating a diagram.

Advertisements

The Importance of Being Testable

October 31, 2010

Designing and building for testability in software at all levels (functional and unit testing) is one of those things most people don’t get. When I first started out in software I remember getting stuck with a last minute task of creating a web client for a test team who needed to test a XML web service. At the time I cursed the task and didn’t really think there was much value in creating the test client. Now though I try and put testing hooks like that all over the place. After looking back at software systems I have designed or worked on, I have realized that one of the main things that people have cursed or praised code on is testability.

Why Testability is Important?

Every developer has their own style for design and coding and some of them are going to think anything else is basically wrong, even if it works. So trying to win people over with coding style or awesome design is a losing battle. The central concept to all good code and systems though regardless of style or design is being able to validate if it works (aka testability). The more you can isolate each part of the system into individual testable parts the easier it becomes for people to feel confident in making changes. Which is ultimately what it’s all about. If someone can come into a system they have never worked on before, make a change, and feel confident about the change, they can’t get too upset.

Designing for Testability

Testability is all about isolation. If you are creating a system with dependencies on another system you need to be able to eliminate the need for that other system for testing. There will be scenarios where you don’t want to have the dependency whether it’s during a unit test or you don’t have access to that system in certain testing environments. Solutions for this could involve the ability to configure different end points at run time and/or putting proxies in front of calls to intercept and return mock responses. The same goes for code, you need to be able to isolate units of code and make them fail or pass tests only if that code is broken. This will involve using factory patterns, dependency injection, and/or other loose coupling strategies.

All Systems Must be End User Testable

Even if your developing a service which operates over an obscure protocol with proprietary message format, there is no excuse for not having a test interface available to allow non-developers to test the functionality. In many cases this means creating a test program or test interface on a system. This may not be in the requirements however it should be. It’s left out many times because they are written in the context of an integrating system which drives testing. Unfortunately the integrating system may or may not be available in all environments and also there could be bugs in the integrating system requiring alternate testing interfaces to validate your system which should validate the need for a end user test interfaces. One of the main places you’ll find integrated systems missing is working locally as a developer. All these aspects of testing make it desirable to get end user testability in what you are developing and it will help people down the line as well.

The No Exception Business Process

September 10, 2010

One of real challenges with custom software is maintenance after the fact. There are always trade offs being made for cost over flexibility. An example that has been a thorn in my side for quite sometime now are business processes developed with no way to plan exceptional cases by a business user. I think the mistake here is idenification of what type of process you are working on. Software developers look at processes and are inclined to think “technology process” not “business process”. With a “tech process” such as rolling logs or backing up files a developer would be right to have assume no exceptional cases are necessary to be administered by a business user. But a nightly business critical process such as moving approved changes or clearing processing queues needs to able to be administered by business users otherwise there will be duplicated efforts, both a business user and a engineer will need to assist. Identifying proper administration over processes will reduce support cost and produce a system which has the necessary flexibility to support the business process.