Demystifying the UML

Demystifying the UML

By Bhuvan Unhelkar, PhD, FACS

Printed in Information Age, Oct 2001, pp56-61, Publication of the Australian Computer Society Bhuvan Unhelkar, PhD, FACS, is the Principal of MethodScience, a consulting and training company specialising in the area of object-oriented (component-based) software processes, modelling, quality and management. He has 19+ years of IT experience, and has authored 3 books, published numerous articles and presented his thoughts, amongst many things, on modelling with the UML, internationally. Earlier, at Dow Jones, he won the ‘Computerworld Object Developers Award’ for ‘Best use of OO approach across the organization’. He is convenor of the object-oriented special interest group (OOSIG) of the ACS.

Modelling, Software and the UML Human progress rests on the pillars of modelling. Financially, and technologically, its far more acceptable to wreck a few airplanes provided they are model airplanes with no real passengers inside. And medical students do not learn even the simple procedure of appendicitis operation by taking them out of live patients. Ditto with construction, and with manufacturing and so on. With only about 50 years of history to talk about, computing, as compared with the aforementioned branches of engineering and science, is still in its infancy. Yet, it is learning fast. Colossal software disasters1 taught an important lesson to the software community - that it was far easier and cheaper to create ‘models’ of software systems than running the gauntlet of producing the actual software and come across major issues of implementation, acceptance and relevance to name but a few. Prototyping was tried, and proved helpful. What was missing, though, was a comprehensive set of notations, diagrams and documentation, supported by corresponding CASE tools and processes, that would enable creation of elaborate business and system models that would use a common ‘language’. Discussions with various stakeholder groups including business users, project sponsors, business analysts, system designers, architects, project managers, quality managers, programmers and testers, could then take place based on these standardized models, enabling improved communication, project management and quality control.

DeMystifying the UML 2 © Bhuvan Unhelkar, Ph.D., FACS Printed in Information Age, Oct 2001, pp56-61 Right on cue, the software community went overboard! Having started with the humble flowchart in the 1960s, and moving on to the Data Flow Diagrams and the EntityRelationship diagrams as basis for their modelling effort in the 1970s, the world of methodologies and processes exploded on the modelling scene with the advent of objectoriented (OO) technology. Perhaps it was the result of bitter lessons of the past, or just the novelty of the OO technology, the software process marketplace was inundated with no less than 27 object-oriented methods in 19932. They had different notations, approaches, resultant deliverables, and supporting CASE tools. Martin Fowler3 lamented in San Jose as ‘recently’ as 1996, “With a plethora of notational differences, many of which are entirely arbitrary, the simple modeller such as myself feels like banging the gurus’ heads together until they pick a common cardinality symbol.” The entire IT world was desperate to work out a standard mechanism to model software. They also wanted a common set of notations and standards, that could be supported easily by CASE tools and, at the other end of the spectrum, could be learnt by university students as a part of their software and management degrees. The scene was set for the arrival of a unified approach to software modelling. This is where the UML stepped in.

What is the UML? The Unified Modelling Language (UML) is a standard of the Object Management Group4(OMG). The OMG is made up of more than 800 members including well-known software vendors and client organizations. While OMG’s first major standard, CORBA (Common Object Request Broker Architecture) was focused on standardizing the middleware architecture, this second major standard - UML - serves the purpose of standardizing all modelling work within a software project. This modelling work includes (a) modelling in order to understand the existing reality and (b) modelling in order to create new reality5. The UML is borne initially out of the unification of three very popular approaches to objectoriented software development viz. the Booch approach of Grady Booch, the Object Modelling Technique (or OMT) of Rumbaugh et. al, and the Object-Oriented Software Engineering (OOSE) approach of Jacobson. Many other methodologists joined hands with these three (popularly known as the Three Amigos) to produce a comprehensive set of notations, diagrams, and specifications as a means of expressing software models. Booch et. al6 have defined the UML as a language for (a) visualizing, (b) specifying, (c) constructing and (d) documenting the artefacts of a software-intensive system. Thus the UML turns out to be a visualizing language that plays a crucial role in requirements modelling, system design, database design, system architecture and, in fact, in any other aspect of software development (such as testing) that one would care to use it! Furthermore, the UML

© Bhuvan Unhelkar, PhD. www.unhelkar.com

DeMystifying the UML 3 © Bhuvan Unhelkar, Ph.D., FACS Printed in Information Age, Oct 2001, pp56-61 spans the gamut of all types of application domains including insurance, banking, airlines, manufacturing and many real-time applications such as telecommunications. The UML has been used to document new web-based developments, integrating with existing legacy applications, CRMS implementations, as well as data warehousing projects. Furthermore, because of its ability to represent object-oriented artefacts7 (such as objects, classes and components) in a standard and understandable way, the UML is easily the most popular modelling language in education and training. Thus it is truly an international de facto standard in modelling of systems.

A Walkthrough of the UML diagrams So, what is the UML made up of? Well, the heart of the UML is a meta-model which, as the name suggests, is the model of a model. All those who have contributed to the UML, have primarily contributed to the meta-model that governs the rules for creating the UML diagrams. Being a visual modelling language, though, our interest in knowing about the UML can start by looking at a suite of cohesive diagrams that make up this ‘language’. A typical list of UML diagrams that are used in practice is shown in the Table below. UML diagrams

Comments

Use case diagrams Activity diagrams Class diagrams Sequence diagrams Collaboration diagrams Object diagrams State chart diagrams Component diagrams Deployment diagrams Package diagrams* Robustness diagrams*

Model functionality from user’s viewpoint Model the flow within a system or a use case Models classes and entities Models the interactions between objects Models the interactions between objects Model of objects and their links Models the lifecycle of an object Models the executables Models the hardware and corresponding components Models subsystems and architecture Models part-architecture separating interface from business models

The number of diagrams listed in the Table 1 may vary, depending on whether an extension to a diagram is considered as a separate diagram itself (for example, the two diagrams with ‘*’ are in addition to the original 9 listed by Booch et al in The UML User guide). Once they comply with the meta-model, the modellers are free to use these diagrams in whatever way they can. This makes the diagrams and specifications that go with the diagrams more or less like a rubber band – they can be stretched to model whatever needs to be modelled (even nonsoftware processes such as existing in business, or telecommunications areas). Therefore, it is important to use the UML notations and diagrams at the right level, by the right people, and in


DeMystifying the UML 4 © Bhuvan Unhelkar, Ph.D., FACS Printed in Information Age, Oct 2001, pp56-61 the right modelling arena. To understand this relevance of diagrams, we divide all modelling work in software projects roughly into three modelling spaces, as shown in Figure 1.

ANALYSIS

DESIGN + CODE

SOLUTION TO REAL WORLD PROBLEM

AR CH IT EC TU RE

Figure 1: The Three Major Spaces of Work in Software (Based on Unhelkar, B., Quality Assurance for UML-based Projects, due 2001, Addison Wesley, Boston)

Problem Space: Here we identify the problem that the business or end-user is trying to solve. This can be a pure business problem, or a problem related to software systems. The end-user and the business analysts’ work together in this space, to create models that will express the problem in a consistent, correct and complete manner. I have called the deliverable model in this space as Model Of Problem Space (MOPS). Solution Space: The modelling effort in this space is directed towards creation of a solution. This would be a technologically driven model, bringing in to perspective the compilation language, databases for storage, and user interface designs. I have called the deliverable model in this space as Model Of Solution Space (MOSS). Background Space: Deals with architectural modelling effort that happens in the background. Expressing ‘thin v/s thick’ client architectures, bandwidth, performance and scalability modelling, introduction of patterns in the design, as well as issues of reuse and quality, forms part of this modelling. I have called the deliverable model in this space as Model Of Background Space (MOBS).


DeMystifying the UML 5 © Bhuvan Unhelkar, Ph.D., FACS Printed in Information Age, Oct 2001, pp56-61 The UML helps in the modelling effort in all three spaces. More importantly, it helps in interaction between the three modelling spaces by enabling expression of one aspect of a diagram into another diagram. This ‘cross diagram dependency’ is an important feature of UML’s value in software modelling. We will now see the diagrams as they are used in modelling in the three spaces.

Modelling Of the Problem Space (MOPS) with UML Two important UML diagrams that form the crux of modelling the business problem are (a) the use case diagram and (b) the activity diagram. This does not preclude modellers from using other diagrams, such as the class diagram, to create the business object models in MOPS. However, the use case and the activity diagrams are almost mandatory for this part of modelling.

Figure 2: A use case diagram for ‘Making a Claim’ in a typical insurance system Figure 2 shows a use case diagram for a typical insurance system. It documents the process of a client making a claim on their policy. This diagram, in my opinion, is one of the most revolutionary diagrams in the entire IT history. It is the first time in the history of computing that a software model includes notation for an ‘all-important’ role in software –the user. Neither the flowcharts, nor the data flow diagrams, in that bygone era of modelling, bothered to show the ‘user of the system’ in the models. Like in the bygone eras when ‘delivering a baby’ used to be a process between the mother and her doctor, with the father, more often than not, relegated to a nervous corner of the hospital, the users of software systems used to get the ‘finished product’. Emancipated thinking led to the father being made a part of the © Bhuvan Unhelkar, PhD. www.unhelkar.com

DeMystifying the UML 6 © Bhuvan Unhelkar, Ph.D., FACS Printed in Information Age, Oct 2001, pp56-61 process of ‘delivering a baby’, and so also with the delivery of software systems. The ‘Actor’, or the role that the user plays now gets identified and represented first by the ‘stickman’ on the use case diagram. In Figure 1, we have a ‘Client’ and an ‘Account Executive’ as actors in an insurance organization, participating in the process of making a claim. Making a claim, though, is a complete use case diagram, which is made up of smaller, manageable, and possibly reusable units of processes. These are represented by bubbles on the diagram, and are called the use cases within the UML. Each use case represents a ‘set of interactions’ between the actor and the system. This interaction has to be documented in the specifications of the UML. This can be done using a text attachment, or pictorially using a sequence or activity diagram. I prefer to use an activity diagram, and for the use case “Lodges a Claim” I have drawn the activity diagram, as in Figure 3.

Figure 3: Activity diagram “Lodges a Claim” for a corresponding use case


DeMystifying the UML 7 © Bhuvan Unhelkar, Ph.D., FACS Printed in Information Age, Oct 2001, pp56-61 Rumbaugh et al8, have called this diagram “…like a traditional flowchart except it permits concurrent control in addition to sequential control – a big difference”. The concurrent control is shown by means of ‘sync points’ (the horizontal bars) that, in business terms, represent parallel workflows. This diagram also has Actors and Swimlanes, that a traditional flowchart doesn’t have enabling role-based process modelling. Figure 3 shows this flow of events, as starting with the activity of ‘completing a claim’, followed by accessing the insurance organization, and lodging a claim. The claim can be lodged across the counter, or over the Internet, or by phone. The business analyst and the user are the main roles in this modelling of the problem space.

Modelling Of the Solution Space (MOSS) with UML Analysis of the use case, its documentation, and corresponding activity diagrams provides a list of candidate ‘business entities’ that are put together in one of UML’s most basic and popular diagrams, the Class diagram. It is a structural diagram that shows various classes (business entities) and how they relate with each other. While a business analyst may put initial Class diagrams together, the system designer embellishes them with a large amount of technical information. Analysis of the insurance claims process leads to the following class diagram in Figure 4.

Figure 4: Class diagram ‘Claims Details’ (resulting from analysis of ‘Makes a claim’ use case diagram, and ‘Lodges a claim’ as one of the many activity diagrams)


DeMystifying the UML 8 © Bhuvan Unhelkar, Ph.D., FACS Printed in Information Age, Oct 2001, pp56-61 This diagram shows classes Claim, Policy, Client, and Settlement. Various types of policies ‘inherit’ from a common policy class. Client can be modelled on a ‘Person’, enabling reuse. Each of these classes will have their own attributes (that describe their characteristics) and operations (that describe their behaviour). Real life modelling exercises contain many such class diagrams, and a class can appear in more than one class diagram. Furthermore, these class diagrams can be directly mapped to the chosen language of implementation, such as C++, Java, or XML. UML-based CASE tools also enable selective ‘visibility’ on these diagrams. The MOPS modellers will not be interested in the gory technical details such as attribute types and operation signatures, so they can hide these details, whereas the designers and programmers can open these details, as and when needed. Code generation is another possibility offered through these diagrams, but practical experience suggests that this feature of UML-based CASE tools should be exercised with caution.

Figure 5: A sequence diagram for ‘lodging a claim’ Note again, though, that the class diagram is showing us the ‘structure’ of the business entities involved. There is no ‘dynamicity’ in the class diagram. The need to show ‘what happens’ and ‘how it happens’ is handled by yet another very popular diagram, called the Sequence diagram. Figure 5 shows the Sequence diagram for ‘Lodging a Claim’ sequence. On the left is the Actor who initiates the transaction, and on the right are the collaborating objects that satisfy the functionality. Both business analysts and programmer again love this diagram, as different views of the diagram provide information on the ‘snap shot’ aspect of the process, at the required level. © Bhuvan Unhelkar, PhD. www.unhelkar.com

DeMystifying the UML 9 © Bhuvan Unhelkar, Ph.D., FACS Printed in Information Age, Oct 2001, pp56-61 The system designer and the programmer are the main roles in this modelling of solution space.

Modelling Of the Background Space (MOBS) with UML The background or architectural space models deal with the implementation details through UML’s implementation diagrams – namely the Component diagram and the Deployment diagram, as showing in Figure. The architects and senior designers decide which classes will be put together to form a component that will implement the classes. Today, it is possible to ‘buy’ many routine components (such as graphics, printing and maths components). Erudite architects will be first looking at the ‘buy’ option, before ‘making’ the software components themselves. This is the criteria of reuse, and results in speedier development. Quality is another spin-off.

Figure 6: A component diagram showing some ‘Insurance’ components


DeMystifying the UML 10 © Bhuvan Unhelkar, Ph.D., FACS Printed in Information Age, Oct 2001, pp56-61

Figure 7: A deployment diagram showing ‘Insurance’ deployment The architect supported by the project and quality managers are the main roles in the modelling of background space.

What is not the UML Sometimes, the UML gets confused with a programming language. “Will the UML replace XML?” is a common question. Please note that the UML is not a programming language – it was never meant to be one. The UML helps in creating extensive visual models for the three modelling spaces, which are eventually constructed into working software using programming languages like Java, C++ and Smalltalk. The UML and programming languages are complimentary. Another important point that should be clarified upfront is that the UML is not a methodology or process. “We don’t need another process, we have UML” is another common erroneous understanding. As shown in Figure 8, the UML can be used by any object-oriented software process, but is itself not a process. Processes or methodologies help a project in fully utilizing the capabilities of the UML.


DeMystifying the UML 11 © Bhuvan Unhelkar, Ph.D., FACS Printed in Information Age, Oct 2001, pp56-61

Q uality Process A Software Process

XP RUP UML UML

(Standardset setofof (Standard Notations&&Diagrams; Diagrams; Notations CASE tool Support) CASE tool Support)

MeNtOR OPEN Other Processes..

Figure 8: The UML, Process and Quality

CASE tools for the UML There are a number of CASE tools in the market that comply with the basic UML requirements. I am occasionally asked to conduct a comparison, and recommend a CASE tool, in projects. However, comparing the UML CASE tools is quite different in nature to, say, comparing a new spreadsheet or a new computer game. It requires a study of the organization and project in which the UML will be used. Some of the criteria that should be applied in selecting a CASE tool for UML include: •

Compliance with UML – the tools should comply with the UML meta model, and should enable drawing syntactically correct diagrams

•

Support of the Development Environment (e.g. Java, XML) – eventually, all models are translated into working code. Supporting creation of programming language specific code is important in selecting UML-based tools

•

Support of Multiple users (Team work) – no real life project does modelling in isolation. Ability of the CASE tool to support many designers working simultaneously and configuration management are important

•

Information Generation (Document and Web publishing) – while multiple teams and many modellers will be inputting into the models, the tools should be able to generate


DeMystifying the UML 12 © Bhuvan Unhelkar, Ph.D., FACS Printed in Information Age, Oct 2001, pp56-61 proper and sufficient reports. More importantly, they should be able to produce internet-based reports that can be selectively viewed •

Support of Reusability (Patterns) – UML-based tools should be able to support reuse by enabling documentation of reusable patterns, both in-house and external

•

Integration with other Products – UML-based CASE tools will have a need to integrate with other tools such as process-tools, configuration management tools and testing tools

•

Costs of Licensing, Deployment – these CASE tools range in price from A$ 2000 to A$ 20,000 per user license. It is important to consider and compare costs, not only of purchase, but also of deploying across the organization. Since most UML CASE tools have been developed overseas, their corresponding support in the Pacific region should also be carefully considered

Some of the CASE tools that I have used, seen being used, and evaluated for client organizations (depending on their specific needs) are listed in Table 2, with their corresponding website addresses. (* indicates the only Australian product; Trademarks acknowledged) UML CASE tool

Web address

Together v5.0 from TogetherSoft

www.togethersoft.com

Tau UML v4.2 from Telelogic

www.telelogic.com

ParadigmPlus v4.0 from Computer Associates

www.ca.com

Visual UML 2.7.0 from Visual Object Modelers

www.visualuml.com

Simply Objects v3.2.3 from Adaptive Arts*

www.adaptive-arts.com

Magicdraw v4.1 from NoMagic

www.nomagic.com

ROSE 2001 from Rational

www.rational.com

Argo UML 0.9 from Tigris

www.tigris.org

Practical Issues in UML deployment When should you not use the UML? ‘When you don’t want to’ is a simple, straight and important answer. If the culture of the software shop is such that (a) everyone knows what everyone else is doing and there is no need for further communication – a utopian dream - or (b) no one cares about what the other person knows and programming is the only macho thing to do – a realistic scenario - , then attempts to deploy UML will meet lot of resistance. In particular, small projects with less than 5 people and a time frame of less than 3 months can get away without modelling (exceptions being pilot projects specifically aimed at trying out the UML). However, even in larger projects, if the teams are not socio-culturally prepared to accept modelling, use of UML usually results in frustration and negative productivity. Last © Bhuvan Unhelkar, PhD. www.unhelkar.com

DeMystifying the UML 13 © Bhuvan Unhelkar, Ph.D., FACS Printed in Information Age, Oct 2001, pp56-61 but not the least, if the senior management does not see value in upfront modelling, and is not prepared to ‘wait’ to see the value forthcoming, attempts to use UML will fail. The best approach, therefore, in deploying the UML, is to have a buy-in from the senior management, and starting with a proper pilot project. This should be a project of some importance within the organization, and it should be a project with a short time frame so that the results have sufficient visibility. Projects using UML should have a mentor on board. Ideally this mentor should have a minimum of 2 years of UML-based modelling experience (and 10 years of IT experience), and should be available at least 25% of the time during the pilot project. Should the organization decide the deploy UML fully, training will form an important part of the commitment. However, for a starter organization, training in UML techniques should be kept separate from training in UML CASE tools, and more time should be spent on learning the techniques and their relevance, than the CASE tools. Also, UML should not be confused with a process. A process (e.g. RUP, OPEN, MeNtOR, XP) should be kept separate from the UML, and its training and deployment, if adopted, should follow the UML deployment. Finally, the iterative and incremental approach of OO software development processes at times overlays the attempt at UML deployment. Once again the process and project management issues, although vital, should be kept separate from UML deployment, and should follow on.

Future of the UML The UML today is the mainstream modelling language in most software projects. Its imminent new release (version 2.0) is expected to contain far more support for web-based development than in the previous versions. It is expected to support architectural work, especially in the areas of e-services, mobile computing and so on. The UML is on its way to becoming an ISO standard. Latest information on the progress and future of UML can be obtained from www.omg.org.

Further Reading “Where do I start?” is a question I am usually asked of both individuals and organizations. An excellent book, that succinctly puts the UML diagrams together, is Martin Fowler’s9 UML distilled, 2nd Edition. It is only after reading this book should readers attempt the Booch et al’s UML User guide, and Rumbaugh10 et al’s UML Language Reference Manual. OPEN modelling with UML, written by Henderson-Sellers and Unhelkar11, is an essential reading for ‘practical case studies’ in using UML with a process. Techies - (especially architects sceptical of the UML - are recommended a look at Enterprise Java with UML by C.T. Arrington12, and Building Web Applications with UML, by Jim Conallen13. McGregor and Sykes14’ A practical guide to Testing Object-Oriented Software, provides excellence source for testing UML-based software. Finally, overall quality process and techniques surrounding the UML find a seminal


DeMystifying the UML 14 © Bhuvan Unhelkar, Ph.D., FACS Printed in Information Age, Oct 2001, pp56-61 reference in Quality Assurance for UML-based Projects: Techniques and Process, by Unhelkar15.

References & Acknowledgements Thanks are due to John Ridge, President of the ACS, for his initial encouragement to write for the Information Age, as well as Peter Davidson for excellent editorial support. Asha Unhelkar deserves special mention for her suggestions and comments in the MOPS section - an area she excels in, in real life, as a Business Analyst using the UML. The UML diagrams in this article have been drawn using an Author’s copy of TogetherControlCenter from TogetherSoft™.

1

As, for example, documented by Robert Glass in Software Runaways Jacobson, I., “Time for a cease-fire in the methods war”, Jrnl of Obj Or Prog, Jul/Aug 1993 3 Fowler, Martin, “A Survey of Object-oriented Analysis and Design Methods”, OOPSLA’96 Tutorial No. 45, San Jose, CA, 6-10 Oct 1996 4 www.omg.org 5 Unhelkar, B., After the Y2K Fireworks: Business and Technology Strategies, 1999 6 Booch, G., Rumbaugh, J., and Jacobson, I., The Unified Modeling Language User Guide, Addison Wesley Longman, Inc., 1999 7 UML, having originated from object-oriented methodologies, is ideal for representing object-oriented concepts such as objects, classes, components as well as inheritance, associations and dependencies 8 Rumbaugh, J., Jacobson, I., and Booch, G., The Unified Modelling Language: Reference Manual” Addison Wesley Longman, Inc., 1999, pp81 9 Fowler, M., with Scott, K., UML distilled Second Edition, Addison-Wesley, 2000 10 Rumbaugh et. al, UML Language Reference, Addison-Wesley, 1999 11 Henderson-Sellers and Unhelkar, OPEN modelling with UML, Addison-Wesley, UK, 2000 12 Arrington, C., Enterprise Java with UML, Wiley, 2001 13 Conallen, J., Building Web Appllications with UML, Addison-Wesley, 2000 14 McGretor and Sykes, A practical guide to Testing Object-oriented Software, Addison-Wesley, 2001 2

15

Unhelkar, B., Quality Assurance for UML-based Projects: Techniques and Process,

Addison-Wesley, Boston, USA, 2002
