> MBLM's approach to development > MBLM's approach to UML
MBLM's approach to UML
For many .NET developers who have come from a Visual Basic background, UML may seem like a foreign concept and it's purpose is often misunderstood.
This page details my approach to UML, and explains how and why it can improve a development team's productivity and raise the quality of the software it produces.
What is UML?
UML is a simple means of illustrating and communicating the relationships in an object oriented system.
Often people work with UML case tools which offer computer aided design, but in its simplest form, UML diagrams can be drawn on a piece of paper or a white board.
Why use UML?
UML is an industry standard means of communicating object oriented systems design.
Developers who understand UML can communicate precisely and effectively with one another about the structures of object oriented systems, minimising the chances of misunderstandings.
New developers to a team who understand UML can quickly grasp the structure of a software application when UML analysis and design documentation is available for it.
UML helps to standardise your software development process and make it easier for new developers trained in UML to come up to speed with your application's architecture.
However, UML is not just a means of documenting software architecture; it is far more useful as a means of planning new systems or adding new features to existing systems.
Very often systems implemented without UML will undergo a number of iterations in which the structure of the application is changed as the problem domain is explored.
This is often extremely costly with every iteration taking up weeks or months of development time.
Exploring a problem domain by implementing code is a very expensive and an inefficient means of coming up with a software solution.
A system that might take months to implement can be described in UML in hours, consequently it is far more efficient to explore a problem domain using UML than it is to develop it in code.
Using UML helps to ensure that the architecture you create in a system is efficient, elegant and speeds the overall time taken to develop the system.
Managing the SDLC
Architectural mistakes in software development almost inevitably lead to extremely costly blow outs in development time.
Not only does this represent a huge cost to a company in terms of development costs, it can also lead to missed market opportunities.
When used with a well-defined process, UML can help identify the scope of a project and make the measuring of its progress easier.
As such, it helps to reduce the risk in software development, empowering management to budget and make effective and informed business decisions regarding software development projects.
UML is flexible
There is absolutely no need to use UML dogmatically.
UML is flexible; whilst offering a definitive notation that can be used to help in the design of the largest projects, it's atomic enough to enable a developer on a smaller project to use parts of it as needed.
UML needn't take up weeks or months of a development schedule, with experience you can gain value from its use within minutes or hours.
Very often it has been the case where I have been involved in a large project lasting many months that has benefited on a daily basis, from UML created in a couple of days at the beginning of the project.
Software quality
One of the key design goals when using UML is to make a system robust to change (extensibility).
Achieving system extensibility needn't involve sacrificing simplicity.
With the right design and approach it is often the case that creating an extensible system does not take any more time to implement than a solution that is not extensible.
When architecting systems, it is important to implement only what is needed to achieve the immediate business needs, but that needn't be at the expense of longer term business objectives.
How is UML used at MBLM Software
A lot of people in the industry (both proponents and detractors) see UML as a strict dogma.
This is not my approach.
I use UML as needed, when there is a need to elaborate and explore parts of the system in which the architecture is not clear or easily understood.
I use UML iteratively, creating or modifying the design as the code is being written.
It is usual that the UML model will evolve throughout the project, with changes and new additions to the design becoming ever smaller as the project progresses.
When using UML I don't attempt to document systems in their entirety, I only document the parts of the system that are complex and require some forethought before they are implemented.
UML is a means to an end, and that end is not UML documentation, it is the development of a well architected system in the least amount of time.
A well architected system design has the following characteristics:
-
Provides the blue print and foundations for the first viable release of a system.
-
Allows for features in future releases of the system to be achieved without a major rework of the design.
-
Minimises the time to implement the first release of the system without compromising points 1 or 2.
UML as documentation
When developing a software application, the code written is based on the UML design.
If during implementation it becomes apparent that a substantial addition or change to the architecture is required, I use UML to determine the change that can be made that will have the least impact on the rest of the system.
As such the UML documents I create reflect the structure of the code that ends up being implemented.
Sometimes however, there will be minor divergences where changes were made that were trivial or non-consequential to the overall architecture.
As such, whilst the design documents may not end up containing every nuance of the code, they remain very useful as documentation for a developer who may need to work with the system.
Unless specifically requested by a client, generally, I do not go back and update UML diagrams for documentation purposes following the completion of a project.
My opinion is that using UML to document aspects of a system that are already well understood or have already been implemented, in most cases, is a complete waste of time and money.