Todd, a bright young software developer and the latest addition to Objektum explores the common perception of UML and shares with us why his view on UML has changed...
Having recently joined Objektum after graduating last year, the team and I thought it would be a good exercise to write down my initial impressions of the work I do with UML class modelling and how it relates to software engineering, as much for your benefit as my own.
It might first be a good idea to give you an overview of my level of exposure to UML before joining the team. The truth is that I was only offered modules covering UML during the first year of my degree and despite choosing advanced programming options in later years the subject wasn’t approached again.
It was very much my experience that we were being taught UML without it ever being explained as to what exactly it was useful for, or how it might be applied to a real-life situation.
One example that I’m sure will be familiar to anyone who has studied UML is modelling a video rental scenario. We would study a text and find the actors and use cases to create a Use Case diagram but then we would move onto the next topic. The step between using the model to conceptualise the problem and actually creating the system was never taken.
It left me wondering just when UML diagrams were actually supposed to be used: should they be used in the planning stages, as a way or document functionality after the fact or as a high level overview for explaining a system? Suffice it to say that I couldn’t immediately tell you the benefits of modelling.
Something that I think my lectures would have benefitted from and something that was quite surprising to me when being shown around the tools and systems we use here in the office is just how easy it is to generate code directly from class diagrams.
Now you might be thinking that it’s a doddle just to sit down and write a skeleton class and start adding methods and attributes and all the rest of it by hand as-and-when you need them, but think about how much longer it would take if you later realised that you needed to inherit from another class.
Traditionally you would have to go to each affected class and add the changes by hand, taking up valuable time and presenting an opportunity for bugs to creep in. Automatically generating classes from a UML model means that all the hassle and potential problems you might otherwise encounter are completely side-stepped and the same task can be accomplished in much less time. Not only that but creating accurate class diagrams makes discussing and reviewing much easier, and you can quickly sketch a diagram on a whiteboard or paper and know exactly what’s going on without the need for pseudo-code.
I don’t expect to have sold you on the idea of using UML in your project quite so easily but I do hope after reading this you’ve at least come away with the impression that UML isn’t just a tool for making diagrams with funny stickmen on, and if you’re hesitant to give UML a chance then it might just pay to ask yourself why, and to look at where your preconceptions come from.
When I mentioned to friends that I was using UML in software development they were very curious as to what exactly I used it for- the general comment being ‘Oh do people actually use that?’. To me it seems to highlight a real problem in the way that UML is currently taught, a problem that only serves to keep model driven development as a fringe activity.
A big subject so can we take a step back, what's the most important part of any project? Answer is requirements. If your ignoring the real world requirements and heading off into your own inventive backyard then no UML model is going to save you from eventually getting burnt so it's crucial that use-cases either in the UML form or what ever form your 'change requests','features' come in do come in from the real world and not from those with plenty of talk but little to back it up (CEO's are often visionary, some have it spot on, some don't, you need to stand up and use your engineering insight, when the next project comes in for a 1080p 1U Fridge comes in you must ask why?! and if that hasn't been answered then walk, don't hang around because bad requirements bring companies down and you don't want to be there when they do.
ReplyDeleteSo back to UML, I've been there since the Shlaer Mellor days and have met Leon Starr many years back, this has always been the way to develop software and the unification of the OO methods has made this process and language accepted on the majority of projects. However, last time I checked 60% of Project Managers and Engineers thought that UML stood for UML Class Diagram and that was all the Project Managers would budget for and all the Engineers were ever planned to do. Wrong. This is a costly way to perform UML, yes from the project plan it looks cheap as your only dropping in 1/2 days at most for each class diagram and old-style managers don't like you 'wasting' your time on design. Once again learn to disagree with your old-style manager and learn to convince them of the benefits of true agile model/test driven development with UML is all about. When you've captured your requirements you can bring out your use-cases these essentially are the building blocks for test cases and the building blocks of your code and the associated project tasks to do all those things.
Whats great is that you can plan very accurately and you produce high quality results (that's if you follow the whole UML/Agile (or full UDP) process and not just produce some pointless class diagram that goes out of date within the first day, that's why having executable UML has always been the future because you can test before an ounce of coding has been done and you have the potential to generate code.
I could go on and on about three winning factors 1) Capture Requirements and use use-cases or something not to dissimilar
2) Do something light weight like Agile inless you have to go all UDP heavy.
3) Execute execute execute, Dont' spend too much time writing blurb like this, you have products to produce, new ideas to turn into real working proven ideas, you don't have time to squander on discussions about why or what, get on with solving problems with design, test then design and then go and either generate it or make it work and prove it by feeding your use-case based test cases into it, iterate re-iterate and you may end up with a solid durable maintainable piece of software that can be maintained from design (not all of it, some code naturally doesn't fit into models and should always be bridged, that's just life!).
Hope you enjoyed my ramblings and they made some sort of sense.