• Date: 4/15/2011

    UML and MDD, a Beginners Opinion


    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. 

    In keeping with the university theme, if this were a lecture this is around the time that I would mention some dusty books for you to go away and read (that you would ignore) so if you're interested in learning more about how good use of UML can be a positive influence on your software project you could do much worse than this well written and practical essay by Leon Starr.
     

    • Latest News