There is a common perception amongst general management that software is both cheap to produce and easy to change. 'Its only a bit of software - it won't take you long'. Developers know that this is not true. Software is extremely complex and, once a particular structure is in place, often long-winded and difficult to change. A building architect knows this and creates a drawing of the building from more than one direction, ensuring that the structure is appropriate for the purpose of the building and that the dimensions are all consistent. Only when this visual model of the proposed work has been approved is the job of laying bricks begun.
Software is very abstract and hard to visualise. A visual modelling language, such as UML, allows software to be visualised in multiple dimension, so that a computer system can be completely understood before construction begins. Furthermore, UML can be used to produce several models at increasing levels of detail. The overall scope of the software can quickly and easily be defined at the start of the project with a high level model allowing for accurate estimation. Increasing levels of detail can then be added to each part of the software as it is constructed, until finally the software appears as code. The code can then be tested against a test model that is derived from the original model of requirements.
UML is appropriate for both new system developments and improvements to existing systems. It is a fallacy that in order to use a new modelling technique on an old system, the old system will have to be completely 're-documented' in the new style in order for any change to take place. The truth is that only those parts that are affected by the change will need to be modelled. If they were badly documented or not documented at all, then a lot of work would need to be done to understand them anyway in order to make the change.
Undocumented or badly documented software has a reduced value as a company asset. With so much of the company's business process embedded in obtuse software code, a company is vulnerable to losing an understanding of and control over the business rules by which it operates. Gradual re-engineering of the company's bespoke computer software in a way that makes the functionality of the software transparent, brings those important assets back under control. It removes the company from dependence on key personnel who may leave at any time and improves understanding of the company's critical business processes. It even improves the quality of software engineering staff because those who want to do a proper job will look for companies that model with UML.
The Unified Modelling Language was created by Rational Software in order to provide a standard for software modelling languages. It is now owned and controlled by the Object Modelling Group, an independent organisation. UML has quickly become the de-facto standard modelling language in the software industry. UML is a universal language because it can be applied in many areas of software development. It includes user-definable extension mechanisms so that it can be adapted for specific environments. Industry standard extensions now exist for business modelling and web-based applications development.
The Use Case Driven nature of modelling with UML ensures that all levels of model trace back to elements of the original functional requirements. This traceability between models comes without the extra effort of creating and maintaining a 'traceability matrix' which can be a complex and time consuming job. The result is that the impact of a requested change can quickly be estimated. A change in requirements can be traced though analysis and design models into those components affected and even lines of code. The code affected can then be traced back to the requirements and total regression testing effort calculated.
UML models respond well to an incremental development environment. It is possible not only to develop only those parts of the model that are required to satisfy the new requirements, but also to demonstrate that all the code needed to fulfill those requirements is in place and that only the code needed to fulfill those requirements is in place. This approach ensures that only the work needed to fulfill the current requirement is done, while still developing in such a way that maximises re-use, maintainability and extensibility.
Large complex UML models can be decomposed in a totally user-definable way so that different parts of the model can developed independently by different people or groups. Furthermore, given the right tools and change management infrastructure, each part of each model can be independently change managed. This facility enables independent, yet controlled and coordinated, working on different parts of a project by different groups. Each group, however, still has full visibility of the activity of other groups and is kept fully aware of all changes that affect its own work. Automatic metric extraction can contribute further to improving estimation.
UML, BPMN, SysML and the corresponding logos are trademarks of the Object Management Group
Enterprise Architect, Sparx Systems and the corresponding logos are trademarks of Sparx Systems
MagicDraw, No Magic and the corresponding logos are trademarks of No Magic Inc
Why Use UML?