Section 1.1. What s in a Modeling Language?

1.1. What's in a Modeling Language?

A modeling language can be made up of pseudo-code, actual code, pictures, diagrams, or long passages of description; in fact, it's pretty much anything that helps you describe your system. The elements that make up a modeling language are called its notation . Figure 1-1 shows an example of a piece of UML notation.

Figure 1-1. A class declaration as it can be shown using UML notation

There are references to the UML meta-model and profiles throughout this book. A more complete description of what the UML meta-model contains and why it is useful is available in Appendix B, but for now, just think of the UML meta-model as the description of what each element of notation means and a profile as a customization of that description for a specific domain (i.e., banking).

However, notation is not the whole story. Without being told that one of the boxes in Figure 1-1 represents a class, you wouldn't necessarily know what it is, even though you might be able to guess. The descriptions of what the notation means are called the semantics of the language and are captured in a language's meta-model.

A modeling language can be anything that contains a notation (a way of expressing the model) and a description of what that notation means (a meta-model). But why should you consider using UML when there are so many different ways of modeling, including many you could make up on your own?

Every approach to modeling has different advantages and disadvantages, but UML has six main advantages:

It's a formal language

Each element of the language has a strongly defined meaning, so you can be confident that when you model a particular facet of your system it will not be misunderstood.

It's concise

The entire language is made up of simple and straightforward notation.

It's comprehensive

It describes all important aspects of a system.

It's scaleable

Where needed, the language is formal enough to handle massive system modeling projects, but it also scales down to small projects, avoiding overkill.

It's built on lessons learned

UML is the culmination of best practices in the object-oriented community during the past 15 years.

It's the standard

UML is controlled by an open standards group with active contributions from a worldwide group of vendors and academics, which fends off "vendor lock-in." The standard ensures UML's transformability and interoperability, which means you aren't tied to a particular product.

1.1.1. Detail Overload: Modeling with Code

Software code is an example of a potential modeling language where none of the detail has been abstracted away. Every line of code is the detail of how your software is intended to work. Example 1-1 shows a very simple class in Java, yet there are many details in this declaration.

Example 1-1. Even in a simple Java class, there can be a lot of detail to navigate through

 package org.oreilly.learningUML2.ch01.codemodel;   public class Guitarist extends Person implements MusicPlayer {      Guitar favoriteGuitar;      public Guitarist (String name) {       super(name);    }      // A couple of local methods for accessing the class's properties    public void setInstrument(Instrument instrument) {       if (instrument instanceof Guitar) {          this.favoriteGuitar = (Guitar) instrument;       }       else {          System.out.println("I'm not playing that thing!");       }    }       public Instrument getInstrument(  ) {       return this.favoriteGuitar;    }      // Better implement this method as MusicPlayer requires it    public void play(  ) {       System.out.println(super.getName(  ) + "is going to do play the guitar now ...");         if (this.favoriteGuitar != null) {          for (int strum = 1; strum < 500; strum++) {             this.favoriteGuitar.strum(  );          }          System.out.println("Phew! Finished all that hard playing");       }       else {          System.out.println("You haven't given me a guitar yet!");       }    }      // I'm a main program so need to implement this as well    public static void main(String[] args) {       MusicPlayer player = new Guitarist("Russ");       player.setInstrument(new Guitar("Burns Brian May Signature"));       player.play(  );    } } 

Example 1-1 shows all of the information about the Guitar class, including inheritance relationships to other classes, member variables involving other classes, and even implementation details for the methods themselves.

What's wrong with using software source code as your model? All of the details are there, every element of the language's notation has meaning to the compiler, and with some effective code-level comments, such as JavaDoc, you have an accurate representation of your software system, don't you?

The truth is that you haven't actually modeled anything other than the software implementation. The source code focuses only on the software itself and ignores the rest of the system. Even though the code is a complete and (generally) unambiguous definition of what the software will do, the source code alone simply cannot tell you how the software is to be used and by whom, nor how it is to be deployed; the bigger picture is missing entirely if all you have is the source code.

As well as ignoring the bigger picture of your system, software code presents a problem in that you need to use other techniques to explain your system to other people. You have to understand code to read code, but source code is the language for software developers and is not for other stakeholders, such as customers and system designers. Those people will want to focus just on requirements or perhaps see how the components of your system work together to fulfill those requirements. Because source code is buried in the details of how the software works, it cannot provide the higher level abstract views of your system that are suitable for these types of stakeholders.

Now imagine that you have implemented your system using a variety of software languages. The problem just gets worse. It is simply impractical to ask all the stakeholders in your system to learn each of these implementation languages before they can understand your system.

Finally, if your design is modeled as code, you also lose out when it comes to reuse because design is often reusable whereas code may not be. For example, reimplementing a Java Swing application in HTML or .NET is much simpler if the design is modeled rather than reverse engineering the code. (Reverse engineering is extracting the design of a system from its implementation.)

All of these problems boil down to the fact that source code provides only one level of abstraction: the software implementation level. Unfortunately, this root problem makes software source code a poor modeling language.

1.1.2. Verbosity, Ambiguity, Confusion: Modeling with Informal Languages

At the opposite end of the spectrum from complete and precise source code models are informal languages. Informal languages do not have a formally defined notation; there are no hard and fast rules as to what a particular notation can mean, although sometimes there are guidelines.

A good example of an informal language is natural language. Natural languagethe language that you're reading in this bookis notoriously ambiguous in its meaning. To accurately express something so that everyone understands what you are saying is at best a challenge and at worst flat-out impossible. Natural language is flexible and verbose, which happens to be great for conversation but is a real problem when it comes to systems modeling.

The following is a slightly exaggerated but technically accurate natural language model of Example 1-1:

Guitarist is a class that contains six members: one static and five non-static. Guitarist uses, and so needs an instance of, Guitar; however, since this might be shared with other classes in its package, the Guitar instance variable, called favoriteGuitar, is declared as default.

Five of the members within Guitarist are methods. Four are not static. One of these methods is a constructor that takes one argument, and instances of String are called name, which removes the default constructor.

Three regular methods are then provided. The first is called setInstrument, and it takes one parameter, an instance of Instrument called instrument, and has no return type. The second is called getInstrument and it has no parameters, but its return type is Instrument. The final method is called play. The play method is actually enforced by the MusicPlayer interface that the Guitarist class implements. The play method takes no parameters, and its return type is void.

Finally, Guitarist is also a runable program. It contains a method that meets the Java specification for a main method for this reason.

If you take a hard look at this definition, you can see problems everywhere, almost all resulting from ambiguity in the language. This ambiguity tends to result in the, "No, that's not what I meant!" syndrome, where you've described something as clearly as possible, but the person that you are conveying the design to has misunderstood your meaning (see Figure 1-2).

Figure 1-2. Even a simple natural language sentence can be interpreted differently by different stakeholders in the system

The problems with informal languages are by no means restricted to written languages. The same description of Guitarist might be presented as a picture like that shown in Figure 1-3.

Figure 1-3. Informal notation can be confusing; even though my intentions with this diagram might appear obvious, you really can't be sure unless I also tell you what the notation means

Figure 1-3 is another example of an informal language, and it happens to be a notation that I just made up. It makes perfect sense to me, but you could easily misinterpret my intentions.

As with the natural language model, all of the details are present in Figure 1-3's picture, but without a definition of what the boxes, connections, and labels mean, you can't be sure about your interpretation (or mine!).

So, why does any of this matter if your team has a home-grown modeling technique it's been using for years and you all understand what each other means? If you ever have to show your design to external stakeholders, they might become frustrated trying to understand your home-grown symbols, when you could have used a standard notation they already know. It also means you don't have to learn a new modeling technique every time you switch jobs!

The basic problem with informal languages is that they don't have exact rules for their notation. In the natural language example, the meanings of the model's sentences were obscured by the ambiguity and verbosity of the English language. The picture in Figure 1-3 may not have suffered from quite the same verbosity problems, but without knowing what the boxes and lines represent, the meaning of the model was left largely to guesswork.

Because informal languages are not precise, they can't be transformed into code as a formal language can. Imagine if Figure 1-3 had a set of formal rules; then you could generate code that implemented the classes for Guitarist, Person, and so on. But this is impossible without understanding the rules. Unfortunately, informal languages will always suffer from the dual problem of verbosity and ambiguity, and this is why they are a poorand sometimes extremely dangeroustechnique for modeling systems, as shown in Figure 1-4.

Figure 1-4. With an informal notation, the problem of confusion through ambiguity still exists

Although natural language is dangerously ambiguous, it is still one of the best techniques for capturing requirements, as you will see when you learn about use cases in Chapter 2.

1.1.3. Getting the Balance Right: Formal Languages

You've now seen some of the pitfalls of using a too-detailed language for modeling (source code) and a too-verbose and ambiguous language for modeling (natural language). To effectively model a systemavoiding verbosity, confusion, ambiguity, and unnecessary detailsyou need a formal modeling language .

Ideally, a formal modeling language has a simple notation whose meaning is well-defined. The modeling language's notation should be small enough to be learned easily and must have an unambiguous definition of the notation's meaning. UML is just such a formal modeling language.

Figure 1-5 shows how the code structure in Example 1-1 can be expressed in UML. For now, don't worry too much about the notation or its meaning; at this point, the UML diagram is meant to be used only as a comparison to the informal pictorial and natural language models shown previously.

Figure 1-5. Expressing the static structure of the Guitarist class structure in formal UML notation

Even if you don't yet understand all of the notation used in Figure 1-5, you can probably start to grasp that there are some details present in the codesee Example 1-1that are not modeled here. For example, the specific implementation of the play( ) method has been abstracted away, allowing you to visualize the code's structure without excess clutter.

The best thing about having modeled the system using UML is that the notation in Figure 1-5 has a specific and defined meaning. If you were to take this diagram to any other stakeholder in your system, provided he knows UML, the design would be clearly understood. This is the advantage of using formal languages for modeling as shown in Figure 1-6.

Figure 1-6. With a modeling language that has a formally defined meaning, you can ensure that everyone is reading the picture the same way