| May 1999 Archived at Pineapplesoft |  | |||
 | ||||
|
The Pineapplesoft Link newsletter covered a wide range of technical topics, see the archived issues. The newsletter was first emailed in 1998. In 2001 Benoît discontinued it in favour of professional writing for magazines. The “May 1999” page was archived in 2003 to preserve the original content of May 1999. | ||||
| ||||
| ||||
| | Home | Contact | Site map | Writings | Open source software | | ||||
|
Welcome to the 17th issue of Pineapplesoft Link. Table of Contents Pineapplesoft Link is sent only to those who subscribe to it. We respect your privacy: we won't sell our address and you can unsubscribe at any moment. If you would like to receive
Pineapplesoft Link free in your mailbox every month,
subscribe now! Pineapplesoft Link now reaches more than 2,500 subscribers. I'd like to see how fast it can grow to 3,000. Please forward this issue to a collegue and encourage him to subscribe. In this month Pineapplesoft Link, I would like to introduce UML. I will also explain why I think UML is very important for computer science. As always, you are welcome to send me your comments, questions or suggestions on the newsletter to [address removed, the newsletter is no longer published thank you for your support]. What is UML? UML stands for the "Unified Modelling Language." It's a new standard published by the OMG (Object Management Group), the same people who brought us CORBA. The buzz around UML is slowly growing. UML is criticized by some as just a drawing tool while others claim it is the next best thing on Earth. I stand somewhere in the middle ground: as I will explain, I believe UML is important for the evolution of computer science. Yet, it is not a revolution but a natural evolution. As the name implies, UML is a modelling language. Furthermore, it is a standard (or unified) modelling language. In other words, UML is a graphical language for computer scientists and engineers to describe the software they are building. Finally UML is designed to support object-oriented and component-based software development. In other words, UML is a standardized tool to draw blueprint of computer software. Is that all? Yes, that's all. Please read on. The Importance of Models I consider moving to a new flat and a larger office. In fact I have spotted a nice building that I am considering buying. If I end up buying it, it will require some construction work, e.g. I will want to change the entrance and redo a few rooms. I have drafted a rough sketch of how it should look. If I end up buying, I will commission an architect. He or she will take my sketches and draw the real blueprint. What's the difference between the two? My sketches are a model of what I want: they describe how the building should look like. However this model is not precise enough for building workers. It does not respect the conventions in use in the building industry, therefore I have to do a lot of explaining. Of course, it may contain errors: some of my dreams may be impossible to build (I'm doubtful about the staircase). The architect's blueprint is another model of the same project. Hopefully, the drawings also reflect my ideas. However he or she will use conventions standard in the building industry: the painter, the carpenter, the electrician, etc. can read it and they will all understand it in the same way. Without it, they probably couldn't work. The blueprint is also more precise: which material to use where, how long to make the wall, etc. This illustrates the importance of models: they are an essential step between the idea and its realization. Furthermore graphical languages are more expressive. A single line contains as much information as ten sentences. There is also tremendous value in conforming to conventions accepted in the industry. By adhering to standard conventions, more parties can read and share the model. This is essential when the model is intended for communication. The language must be widely understood and unambiguous. Back to UML UML attempts to be the standard set of conventions for modelling in the software industry. In that effort, it draws on past experiences both from within the software industry (UML builds on previous modelling languages such as entity-relationship, Booch, OMT, etc.) and from outside the software industry (e.g. some parts of UML are clearly inspired by conventions in used in the electronic industry). Fortunately UML is largely a graphical language because drawings carry more information per square inch. It does not mean it's just picture. The language is as precise as an architectural blueprint. Many industries rely on some standard modelling language: we have just discussed architecture but electricity and electronics have a modelling language also: there are specific symbols for transistors, lines, plugs and specific convention on how you combine these. Likewise for cartography. Imagine how difficult reading a map would be if you could not rely on the convention that a road is a line? There are also common symbols for viewpoints, churches, hospitals, etc. Sewing is yet another example. There are specific symbols, used in patterns, to indicate where to cut and where to sew. I hope this shows that some form of standardized modeling language is required to fulfil a very basic need: the need for communication. The language makes it possible for the various persons involve in a project to share information clearly and unambiguously. What UML is Not UML is a modelling language for the software industry. It is not a methodology for creating models. UML will tell you how to draw the various components but it won't tell you how to select these elements. Nor which combination is the most sensible. There are many methodologies already and they are good reasons for such a diversity: depending on the specifics of the problem, the culture, etc. the approach to modelling is different. However the resulting models should be in a standardized form (UML) for communication purposes. It's important that anybody can read the models. A Standard is Born The software industry is young. So far, it has managed to move forward without a standard modelling language. However this is causing all kinds of problems: teams who have worked independently find it difficult to communicate. Indeed, as a consultant, I often work with different teams. The lack of a common language means that we very often have to spend lots of time agreeing on a common vocabulary at the beginning of a project. This is very costly as it has the same discussion taking place every time somebody joins the project. UML address this communication problem. In the future, teams who rely on UML will be able to share information more freely. Obviously, this is still the early days of UML but, judging by the warm reception UML has achieved so far, I believe many people think it's time to address the communication problem. Transition to UML need not be difficult because it's not a methodology, just a language. You need not change the way you design software, only how you express the results. Use the technique you like and are familiar with but write the result in the new common language of the software industry. Don't miss the new article:
Pineapplesoft Link is published freely, every month via email.
The focus is on Internet applications in its broadest sense:
distributed and mobile computing, e-commerce, Java, XML, etc. The
articles target people interested or concerned about technology
either personally or professionally. Editor: Benoit Marchal Acknowledgements: thanks to Sean McLoughlin MBA for helping me with this issue. Back issues are available at <http://www.psol.be/old/1/newsletter/>. Although the editor and the publisher have used reasonable endeavors to ensure accuracy of the contents, they assume no responsibility for any error or omission that may appear in the document. Pineapplesoft is a registered trademark of Pineapplesoft sprl in the Benelux. Last update: May 1999. |