.Open A Quick Guide to The Unified Modeling Language (UML) This answers some Frequently Asked Questions about a popular notation. . What is the UML The UML is a common diagrammatic language developed by Rational .See http://www.rational.com/uml/ with the support of all the big computer companies. It is now maintained by the Object Management Group. Rational was bought by IBM who now provides many tools. . Why use the UML Many people think in pictures and a picture can express a lot of ideas in a quick way. UML is a standard way to draw various views of a piece of software: the user's view, the architecture, the internal structure of the software, the source code, and the hardware involved. If you become familiar with the UML you will find that you will be able to think of more ideas and also to work out how good an idea is. You'll be able to share your idea with others. $UML is becoming valuable in the job market. .Open When to Use the UML Use a diagram when you need to think about something, share ideas with someone else, save an idea for the future, show management the work you've been doing, when you can't find a bug in code, or when your teacher/adviser requires it. You can use the UML to make rough sketches, to express a blueprint of the code, as input to a code generator, or as required documentation of a finished project. Keep it simple -- only use the UML when you need it. Draw diagrams that give most value. For example, don't draw a deployment diagram unless the software is running on many machines. Don't draw a component diagram when there is only one component -- the main program. Don't worry about packages until you need to have 10 or more classes. The UML helps with these tasks: .Table .Row Understanding and planning Procedures .Item $Activity Diagrams .Row Understanding what user's want to do .Item $UseCase diagrams and $Scenarios .Row Understanding the organization and its problems .Item $Domain .Row Working out detailed object-oriented designs .Item $Sequence and $Communication diagrams. Start analyzing $Scenarios with a $SSD of one of them. .Row Working out an algorithm for a complex operation .Item $Activity Diagrams .Row Designing a data base .Item $Class and $Domain models .Row Designing the software .Item $Class, $Object, $Activity, and $State diagrams .Row Planning and describing the modules in a complex project. .Item $Component diagrams .Row Tracking the source, data, and executable files .Item $Artifact and $Deployment diagrams .Row Planning how to use the hardware .Item $Deployment Diagrams .Row Organizing the work in a project into folders .Item $Package Diagrams .Close.Table In all diagrams, never draw more detail than you actually need. Omit things that are not important or are uninteresting. Notice that you often have to add comments or text to a diagram using English, Mathematics, or Java/C++ syntax. .Close When to Use the UML . How do you draw diagrams in the UML (howtodraw): First: only draw a diagram when you need to: to clarify your thinking or to record for the future what you've decided. Second, UML is a flexible set of diagrams. Here are some ways to use them: .Table Purpose Tool .Row In class or working something out by yourself .Item Draw roughly and quickly by hand with pencil, eraser, and paper. .Row Working on a problem with others .Item Use a chalk board with/without post-it notes. Record with a camera. .Row In a meeting .Item A laptop+tool+projector. .Row Preparing a simple diagram for handing in or presenting to others .Item Use a simple Graphics tool like Dia or Visio. PowerPoint, Word and Corel WordPerfect can do adequate diagrams. .Row Working on a Complex Project or in a team. .Item Use a Computer Aided Software Engineering (CASE) tool like Rational Rose. If the team doesn't have its own space look into Web repositories like Google Groups to hold the files. .Close.Table .Open UML Diagrams . What does the User Want (UseCase): A use case names a type of user (actors) and something that they want to do ($usecase). An actor can be a human, a device, or a piece of software but it must not be part of the system we are producing. The use case describes how an actor achieves a specific tangible goal. The important part of a usecase is the description of the steps that the actors take to achieve their goals and how the system appears to respond to the actors actions. Use any tool to write these $Scenarios. The UML provides a diagram that is good for summarizing a collection of use cases. The actors are drawn as stick figures. The things that they want to do are shown as bubbles. Notice that the icons are drawn just like in the next diagram. .Image uml.usecases.gif Two users and three Usecases Rules: The actors must not be part of the software that you are describing. They are outside it and use it. They can be people, machines, or other software. Usecase names must describe some activity that an actor wants to do. A simple rule is to start each usecase name with a strong verb: "Review grade", "update record", "Get money from ATM", and "Control nuclear reactor" are good names. "Grades" and "do email" are bad ones. Avoid having a large number of overly simple usecases that can be covered by one simple one: Instead of "add record", "change record", "delete record", "print record",.... etc use "Access and update record", for example. Use $Scenarios to show this detail. (Scenarios): Each use case will need to be described in more detail before you work out how to implement it. A scenario describes, step by step, how a particular user gets what they want from the computer. It says what the user does and what the computer does as a result. However it does not spell out all the details -- things like whether there is a tool bar or the color of the screen is best left out. It also pays to be very specific about the particular user you are describing. Similarly, at the start of a project only list the obvious and straight forward scenarios. Add special $extensions to handle the exceptional cases later. Student Enrolls in Class: .List Jo Doe goes to the phone and identifies his/herself. The computer gives a list of things that a student can do to the system. Jo asks for a list of sections in a course. The computer shows Jo the sections he or she is interested in. Jo selects one section to enroll in. The computer records the enrollment and confirms that Jo is enrolled. .Close.List (extensions): It is also possible to record the things that can go wrong (extension points) and provide alternate scenarios (extended scenarios) for handling them. . What does the User Think its all about Many users and usecases share some common ideas or concepts. These form the basis for classes that the software will need. It is also possible to clarify how these classes of objects are related. The links between them define what interactions are possible between different classes of objects. The whole plan is called an architecture. (Domain): The trick that makes object-oriented designs easier to work with is that we use classes in the code that reflect the world in which our clients and users exist. The picture of the user's world can be called a .Key Conceptual Model, .Key Business Model , or a .Key Domain Model. It is an excellent source of ideas for classes inside an object-oriented program. It is also the perfect model to start the design of a data base. Both $Domain and $Architecture models are a collection of boxes which contain just the names of the types of objects you expect to be in the software. Show their interconnections as links between the boxes. You can add more detail if you want -- role names and multiplicities can help clarify the meanings of links. .Image college.gif Model of a College It sometimes clarifies a diagram if you list the attributes of some of the classes in a domain model or architecture. In a complex project you tabulate the attributes for each enity in your domain model -- the result is called a .Key Data Dictionary. These diagrams are also drawings of the data base. In some projects you may have to use a more complex notation called an Entity-Relation-Attribute diagram instead. In a database, domain, or conceptual model avoid all verbs! The names in the boxes should be names of real entities. For example, the name "Enroll" is not a good name for for a box. It describes an action. "Student" is a good name. "Enrollment" is also a good name. Actions appear in usecase scenarios (see above) and operations in sequence charts, collaborations, and class diagrams (see next). . Which Object does What Thinking about how objects work together to do something for the user is important. In other words we model the Interactions between the objects in the software. UML .Key Interaction Diagrams are $Sequence diagrams and $Communication diagrams. Both diagrams help you design interactions. $Architecture summarizes the result. (Architecture): An architecture is a picture of the types of objects in a system plus a list of their attributes and `operations` that these objects will perform to meet the users needs. Add operations to classes at the same time as you sketch $Sequence and $Communication diagrams. (Sequence): In a Sequence diagram you show the users (stick figures) and objects at the top. A vertical line goes down from each of these. Arrows show one object sending a message or calling a function or operation that belongs to another object. A big X indicates that an object deletes itself. What happens in the software when student Jo Doe (`jo`) drops a section(`s`): .Image uml.seq.png A Sequence Diagram (Hint when designing): A System Sequence Diagram or .Key SSD is a good first stp towards a design. It shows all the steps in one scenario as messages flowing into the complete system under design. You typically have 1 or more actors and a single ":System" object. Draw one when you start to analyze a scenario to prepare to design objects that implement or realize the scenario. Then draw a Sequence or Communication diagrams for each step in the SSD. (Communication): In a Communication diagram actors and objects can be anywhere and sequence is shown by numbering the messages that are sent. These show the overall communication pattern but make the sequence of events less clear. What happens in the system when Jo Doe adds a Section .Image uml.comm.gif A Communication Diagram Note -- in the above diagram I have used the simple numbering scheme used when UML was first invented. In the more complex CASE tools the $Class diagrams and these diagrams are linked together: adding an arrow on a Sequence or Communication diagram helps you to add an operation to the class diagram. Or when you add a new message the $CASE tools can list the possible messages (operations or functions) you might want to send. (Collaboration): This is the old name for what is now called a $Communication diagram. They were more complicated, see .See ./uml.collab.gif for an example. . How are the classes organized (Class): The UML can express most things you can code in C++. A single box represents a class of objects. The name of the class is at the top. In the next part of the box list the data each object contains. In the third part of the class box list the operations (functions) that an object can carry out. .Image uml1.gif Diagram of a Class Notice that instead of the C++ 'int example(float x)' we have 'example(x:float):int'. Also omit the word `void` in all UML diagrams! Note: you can sketch a UML class quicker than you can write a C++ class. Many classes can be put on one diagram and connected together with associations: .Image uml04a.gif The Enrollment class Here are all the links commonly used in a class diagram: .Image links.png The 4 main links in UML class diagrams C++ classes have data members that are part of the state of the whole object. In the $UML we can use the dark diamond to indicate that the class is composed of the components. The UML has two or three ways to show this. For example, here is the code for a class called Period: .As_is class Period { .As_is private: .As_is Time time[2]; .As_is vector day(5); .As_is };//end class Period Here are a couple of valid diagrams that show that each Period contains a pair of times and up to 5 days. .Image uml.period.gif Composition of Period A simple composition with a multiplicity of one indicates a simple data member in the C++ class. A fixed multiplicity suggests an array. A range of multiplicities or an asterisk suggests a more complex data structure such as a vector, list, or set. If the order is important, then the constraint "{ordered}" should be put at the end of the link. An vector is an ordered collection of variable size. If the data is accessed via a pointer then a simple arrow should be used to indicate this: .Image uml.pointer.png [Example ----> Pointee] Note: older books used to put an uncolored "Aggregation" diamond at the other end of the association to show a pointer. Note: If there is a vector (or list etc) of pointers then use the arrow with a variable multiplicity. (Object): It helps to be able to draw objects as well as classes. The rules are simple: use a box, underline the name of the object and its class, and put attributes in a compartment under the name. Here for example is a simple Counter class plus object diagrams of of an object `the_count` before and after a particular operation is applied to it. Class Diagram of Counter .Image counter1.png Counter class A recently constructed Counter object called the_count. .Image ch08c.gif the_count when constructed has state=0 The same object after being sent a count() message .Image ch08d.gif the_count after count() has state=1 . How and When does an Object change (State): Often we need to think about how an object changes. Class diagrams give us a static picture of an object and its relations to other objects. Computer Science developed a theory of automatic machines (automata) that lead to the `StateChart` notation. This is part of the Unified Modeling Language. It lets us show when and how an object changes its behavior. Each change of behavior is modeled as a change of the objects internal `state`. The diagram shows these and the allowed changes between them. For example a Student starts out as a Person and then can evolve to be an Undergraduate or an Graduate. Undergraduate can become a Graduate. .Image uml.states.gif State Diagram of a Student Each state is shown as a rectangle with rounded corners. Starting and finishing points are shown as black blobs. Changing state means the object changes it behavior. The change (or transition) is shown as an arrow. Each arrow should be labeled with a mutator method or operation. So the arrows show what operations can be called in a given state, and show you how the operation changes the possible behaviors. Initially we can omit the labels and one state can be used as an abbreviation for a whole pattern of behavior: You can add a lot of extra information to a State chart -- the operations that trigger changes of state, the conditions governing which transition to follow, and what operations are executed when entering and/or leaving a state. . How is a complex problem solved? What is the Algorithm? (Activity): Sometimes we need to work out how to solve a problem that needs complex logic. UML State charts have evolved to allow us to draw Activity diagrams that look like old fashioned flowcharts. Below is one form of binary search for a target in a sorted array or vector of items: .Image activity.gif Activity diagram of a binary search .Image uml.act.png Selected symbols used in UML activity diagrams .See ./uml.act.dia . How is a complex architecture organized? When we have a lot of classes (more than 20 say) we need to group them. We would start to organize our code, diagrams, and documents into folders (or directories). In the UML we can also organize our organize our thinking into "folders" called packages(See $Package below). We can also group our classes into larger modules called components (see $Component below) ready for people to use. A component is plug-compatible: the user knows that it can be replaced by a similar component. A Pckage is more of an aid to the software engineers developing the software. When we code components we produce $artifacts(see $Artifact below). This is the third way that UML supports organization. (Component): A component is very like a class. But they are designed to provide certain interfaces and use others. It is a plug-compatible piece of software that often contains many classes. There is a `lollipop` notation for showing how components are plugged together. Here is an example: .Image lollipop.gif Components The lollipop indicates the .Key interface between the component and its clients. (Artifact): In any real project there will be hundreds of files involved. These used to be shown as components but are now documented as $artifacts. .Image modules.gif Files The above diagram treats each source, object, and executable file as a separate component. Notice the `stereotypes` that tell you the kind of $artifact that I'm using -- an executable program, a file, a document and so on. Here is a list of standard ones: .Table Stereotype Meaning(UML2) .Row <> A physical file in the context of the system developed. .Row <