We have mentioned UML a couple of times before, it's time to take a look and see what it is.
UML stands for Unified Modeling Language - a standard language for specifying, constructing and documenting all sorts of systems, software or other types. UML was initially developed by James Rumbaugh, Grady Booch and Ivar Jacobson in order to give all developers a standard communication language in which they could discuss the general architecture of the program and the best solutions available. As it proved a remarkable software design tool, UML became the official standard for software architecture in 1997, after receiving the support of the biggest names in the industry, such as Microsoft, Oracle and IBM.
UML is independent of any programming language, but it encourages the use of object-oriented tools. The notation is big, but very flexible - that's the idea when being "universal", of course. So, UML is a notation - not a methodology, not a process or anything else, and that's important to keep in mind. You will still need a modeling process, and how you approach it is entirely your choice. Basically, UML defines a number of diagrams and their meaning. It may not seem like much at first glance, but it means you've never had to work with large teams of developers - who, basically, speak different languages, making communication impossible. Each diagram was created with the purpose of allowing all the developers, as well as the clients, get a view of the system. How abstract is your representation is your decision alone.
There are twelve standard UML diagram types, which fall into three categories. The model management diagrams include Models, Packages and Subsystems. The structural diagrams include Class, Object, Component and Deployment. The behavior diagrams include Use Case, Sequence, Activity, Collaboration and Statechart.
These diagrams should not be scary or confusing, on the contrary, even if some of them may get really big. Keep things simple and organized with some very simple tricks. For instance, use colors to draw attention to one thing or another. Don't let your lines intersect, this is messy and confusing. If they must cross, use a "bridge" to show that they do not intersect, in a three dimensional view. Make a different diagram for the primary structure and behavior and then move on to present the details on a separate diagram.
No matter which method you use, it's generally a good idea to start with the dynamic models, such as the use cases, ad to move on from them to static models, such as class diagrams. In this way, you won't have to "guess", by looking at the static model, which class could be used for which operation. The use cases, which are driven from the real needs of the clients, will guide you through the process. Also, in this way you will make sure that everything can be easily traced back to its origin quickly.
The UML 2.0 specifications are even more focused on architecture and will allow even easier control and organization, with the introduction of Infrastructure, Superstructure, Object Constraint Language and UML Diagram Interchange.
Leave a Reply