Implementing the UML in Software Projects

Introduction

Businesses, particularly in the IT sector, are very often faced with new and changing technologies. The decision to be made is whether to embrace the new technologies or continue doing business in the old, familiar ways. One of these new technologies is object oriented software development and the Unified Modelling Language.

Much has been written about the benefits of using object oriented techniques to analyse and design software systems. These benefits include more robust and reliable software systems, easier debugging, maintenance and enhancement cycles, easier scalability to larger systems and reuse of code between projects. Less has been made of the disadvantages: mainly learning and applying new patterns of thinking, new technologies and new ways of running software projects.

When all is said and done, object oriented software development is here to stay and will play a large, and possibly pivotal, role in the future of any software development. Hand in hand with object oriented analysis and design, goes the de facto industry standard method of documenting the design, the Unified Modelling Language (UML).

UML in the Life of a Project

The UML is a set of twelve diagrams with which you can document your design. It does not prescribe any specific process or methodology for arriving at the design - this is a decision of your own choice. In choosing a standard method of documentation from the beginning of your analysis phase to the final coding steps, you empower all the stakeholders from the clients through to the analysts, architects, developers and programmers to participate and understand the design.

You choose different diagrams to document aspects of your design to different stakeholders at different times in the design process. In the beginning of your analysis phase, you would use activity diagrams (similar to the familiar data flow diagrams) and use case diagrams to document the functional requirements of the system and the steps to be executed during each functional requirement. These are used by the clients and analysts to decide on the scope of the project.

For high level views of the system, you can use component and deployment diagrams to show the components within a system, and how these system components are deployed on which computers.

As you move into the more detailed design phases of the project, you will use class and object diagrams to model the key system concepts and their relationships (i.e. client, invoice, order, way-bill, etc.). These diagrams will be used throughout the whole process, becoming more detailed as the project progresses. Sequence and collaboration diagrams will be used to document the dynamic behaviour of each system use case, i.e. the messages sent from one object to another when stepping through a use case. State diagrams are used if there are complex classes which have many internal states (i.e. an order moving from pending, to filled, to delivered, to paid, etc.).

To manage all these diagrams, the UML also provides package, model and subsystem diagrams to organise the diagrams into logical groups.

It is important to remember that not all diagrams have to be used all the time! Only use the diagrams that are needed and that add value for the developers and the stakeholders.

Upskilling your team

Incus Data can provide you and your team with the OOAD and UML training that you need to make your next (or first) OO project a success. We have been training programmers in both procedural and object oriented languages and systems development since 1988. We have a number of OOAD/UML courses:

• Object Oriented Analysis using UML
• Object Oriented Analysis and Design using UML
• Object Oriented Implementation

Lewis Coosner: 2005

Home   |    Top of this page   |    Contact Us    Schedule   |    Course List   |    FAQ   |    Sitemap

Essential Skills for IT