I think that any software developer likes to see the design of his system in UML just as any engineer might like to see the schematics of a system that he has designed (as opposed to just seeing the final package). For that last few years UML has been put forward as the way of expressing software design. Unfortunately, in the harried trenches, most people can not even understand UML, and often its utility is questioned. Personally I like UML, but mostly because a UML tool will give you a way to diagram a system without forcing you into the endless tweeking of diagrams that you often have to do when making them in word or visio.
So you see, I like UML (and I have spent a lot of time and effort trying to apply it to my everyday work), but even I find it difficult to justify. And I have made zero effort trying to force my co-workers to understand it. Why is this? Is it because secretly I question its utility also. In fact I do question its utility for developing software systems. This week we were trying to come to grips with implementing in new and rather complex system. In terms of our normal project size, this is a good one - not so big that it can not be done, not so small as to be trivial. This for me is where UML comes in. Recently in Queue there have been a series of articles on UML fever and how to get cured of it. The most profound statement of this set of articles for me was that you can use UML to explore the design space (and while doing so, learn how the software should be implemented), but you are still developing software, not UML diagrams. I must say I find this to be a revolutionary way of approaching a problem.
I find that creating a quick UML project (I am using Enterprise Architect) where I can define a set of requirements, hack up a few simple use cases with a scenario or two and then do a simple activity diagram or two allows us to have a concrete base to discuss the design. After this I will (rarely) hack up a few simple class diagrams, but more often than not, I just discuss the ideas with co-workers and we can then start the developement from notes on scraps of paper. The UML diagrams and notes are referenced but are never followed in detail. The thing is that the UML diagrams are just tools to explore the design space. I really don't think UML should be used to over-specify systems where the architechs create every object and every method and the developers just add the boilerplate. This is the way most tool venders feel that you should be using the tool.
But then, have you ever reverse engineered class diagrams from existing code? The result, while it may be pretty and it may impress the boss, is actually almost useless.
Thursday, April 21, 2005
Sunday, April 03, 2005
Software Quality
Last week I finished reading the QA issue of Queue magazine (for those of you who are ACM members or live in the US or Canada this is a great magazine and it's free - go to ACM Queue and check it out). Anyway, the quality issue got me thinking about software quality. For me the main downside of having crappy software (and I have that) is that I have to spend more time in maintenance and on the phone with customers that I do hacking new code.
Anyway reading the QA issue made me think of three main issues to investigate. First, is code coverage. We already try to do unit testing (and even unit testing before implementing the tested code) but I am affraid our test don't really address the real issues. I think code coverage would help us focus our testing effort. I went to the Clover .NET home page to check out a demo and was quite impressed (see the report screen shots at Cenqua). I have not had time to try it on our code, but I indend to do this my first free moment (I am writing some overdue system proposals right now - yuck).
The next thing that I think is cool is code reviews. We are a small group so a code review is someone else reading code and signaling parts that suck. I have a good plugin for eclipse ( Jupiter) but I need something for .NET. I found CodeReview and it seems quite cool. I have a project where we have manditory code review, and I will be trying it out. I would just like something where we could annotate lines and have someone respond to the annotations. I think it will really improve the quality of the code.
There is one final area that I think we can address quality issues. That is using the P4 report tool. This allows us to see the files and project in the SCM that have had the most activity. This should allow us to look at these places for bugs first. I think I have to move all my DHTML to P4 (from PVCS) as soon as possible...
Anyway reading the QA issue made me think of three main issues to investigate. First, is code coverage. We already try to do unit testing (and even unit testing before implementing the tested code) but I am affraid our test don't really address the real issues. I think code coverage would help us focus our testing effort. I went to the Clover .NET home page to check out a demo and was quite impressed (see the report screen shots at Cenqua). I have not had time to try it on our code, but I indend to do this my first free moment (I am writing some overdue system proposals right now - yuck).
The next thing that I think is cool is code reviews. We are a small group so a code review is someone else reading code and signaling parts that suck. I have a good plugin for eclipse ( Jupiter) but I need something for .NET. I found CodeReview and it seems quite cool. I have a project where we have manditory code review, and I will be trying it out. I would just like something where we could annotate lines and have someone respond to the annotations. I think it will really improve the quality of the code.
There is one final area that I think we can address quality issues. That is using the P4 report tool. This allows us to see the files and project in the SCM that have had the most activity. This should allow us to look at these places for bugs first. I think I have to move all my DHTML to P4 (from PVCS) as soon as possible...
Subscribe to:
Posts (Atom)