0. Universal Modeling Language (UML)
Rajiv Ramnath
Director
CERCS for Enterprise Transformation and Innovation (CETI)

1. UML: A notation for capturing work products
10/25/2011
UML

2. Uses of UML As Sketch As Blueprint As Programming Language
Concepts (e.g. in a domain model)
Specification (of software components)
Implementation (tied to a language)
To begin with, know that UML can be used in three specific ways:
As a sketch, which is a way to document the results of a design or analysis of a system.
As a construction document or blueprint, which is a specification of a software system using UML, which the implementer can take and build the system
As a programming language, which is where you create a specification for a system within UML and that specification is executable. Ideally, the UML itself can be executed, or, more realistically, from that UML, code can be generated, which can then be executed.
10/25/2011
UML

3. Use Case Reference: UML Distilled, Martin Fowler: Safari
Here is a use case captured in UML. I won’t go into the details of the use case here, because you have seen it before. UML simply incorporated the standard notation of use cases.
Reference: UML Distilled, Martin Fowler: Safari
10/25/2011
UML

4. Use Case Diagram Showing <<Extends>>
In this particular diagram, we have shown the “extends” relationship between two use cases. The extends arrow (or extends edge) is drawn from a use case X to a use case Y to indicate that the process X is a special case behavior of the same type as the more general process Y. You would use this in situations where your system has a number of use cases (processes) that all have some subtasks in common, but each one has something different about it that makes it impossible for you to just lump them all together into the same use case. In this case Distribute Transcripts and Distribute Fee Schedules extends Distribute Information to Students.
Reference: UML Distilled, Martin Fowler: Safari
10/25/2011
UML

5. Use Case Diagram Showing <<Uses>>
The uses arrow (or uses edge) is drawn from a use case X to another use case Y to indicate that the process of doing X always involves doing Y at least once (although it may involve doing it many times, "at least once" is the only relationship guaranteed by this symbol.) This symbol can be referred to as an aggregation operator, because it indicates that a given use case is an aggregate (made up of parts) whose components are the use cases that it uses. If a certain use case uses several others, that means that all of the component use cases must be completed in the process of completing the aggregate use case, although there is no specification in UCDs of the order in which these are completed. A brief, mnemonic way to think about the uses arrow is that it can be read X uses Y means that "X has a Y" as part of it's behavior.
Reference: UML Distilled, Martin Fowler: Safari
10/25/2011
UML

6. Class Diagram Reference: UML Distilled, Martin Fowler: Safari
This next diagram is a class diagram. So here are the things to look for on this class diagram:
Look for the square boxes: these represent classes. The class diagram essentially shows the classes and the relationships between classes.
The lines with the arrows represent relationships. Note something about these relationships; the cardinality of the attribute is indicated at the beginning and end of the arrow. This denotes how many of the source of the arrow relates to the target of the arrow, with the asterisk (*) meaning zero to infinity and a number meaning that specific number. So in this particular case, a particular customer can have many orders, but each order can have only one customer. The arrow that connects the two is known as an association arrow. There are many kinds of associations, but we will just show, in this diagram, the highest level association, which is known simply as an “association”.
Another thing to note is what is known as a constraint. You will see something that says “if Order.customer.getCreditRating is “poor” then Order.isPrepaid must be true.” Constraints are ways of saying something about the relationships between instances of classes that cannot be said diagrammatically. It’s a programmatic way of saying something about the relationship that we haven’t found an easy way to show in a diagram.
The next relationship you will see is something known as a “generalization” relationship, which is nothing more than an inheritance relationship. In this case, Customer is the superclass of Corporate Customer and Personal Customer. This basically means that Corporate and Personal Customer are related to Customer through a generalization relationship.
Also within each class you will see attributes. Within Order Line class, you see quantity and price, etc. Note that in some cases, the types of the attributes are given and in some cases, they are not given. The idea is that as you get deeper toward more specificity, you give the types of the attributes. When you are just capturing what the class is about, you just list the attribute without a type because you haven’t decided the type yet.
The next thing you will see is operations. Inside Corporate Customer, you will see billForMonth() and remind(); these are operations. Operations are also called messages. When you are representing classes at a high level of detail, you might simply list the operations and not show return types and parameters. As you understand the system better or do design, these operations will become methods within that class and in that case, they will have things like return types and parameters.
Reference: UML Distilled, Martin Fowler: Safari
10/25/2011
UML

7. Association Reference: UML Distilled, Martin Fowler: Safari
Sometimes you’ve got to pull an association into its own class. The best reason for doing this is when the relationship has attributes that cannot be suitably put within either of the two classes. In this case, there is an Attendance association that links Person and Meeting. There is an attentiveness attribute that represents the attentiveness of the person in the meeting. You can see that this cannot exist in Person because it must be within the context of a meeting and it cannot be in Meeting because it must be within the context of a person. So the right place to put it is within the Attendance class.
Reference: UML Distilled, Martin Fowler: Safari
10/25/2011
UML

8. Object Diagram Reference: UML Distilled, Martin Fowler: Safari
Here is an example of another diagram known as an object diagram. This diagram is used to show the relationships between specific objects within a system. In this example, you see an engineering Organization whose location is Boston that is the parent Organization of two other organization, the tools Organization in Chicago and the apps Organization in Saba and then two specific Persons, Don and John, who belong to the tools Organization. Note, once again, that this is showing the relationships between specific objects within a system.
To see a class diagram of what this would look like, look to the right. Here you will see three classes, Party, Person, and Organization. Person and Organization are subclasses of Party. Organization can have zero or one parent and that parent can be a Party.
Just to make sure you understand this, take a look at this object diagram shown here and make sure that it can be created by instantiating certain objects in the class diagram and then relating them together.
Reference: UML Distilled, Martin Fowler: Safari
10/25/2011
UML

9. Sequence Diagram Reference: UML Distilled, Martin Fowler: Safari
Now let’s look at the first of many diagrams intended to capture the dynamic behavior of a system. This diagram is known as a sequence diagram. It shows interactions between objects in a system. In fact, it used to be called an Object Interaction Diagram until it got renamed in a later version of UML to sequence diagram. In this particular diagram, you see four objects: an Order, an Order Line, a Product, and a Customer interacting, presumably, to fulfill an order. Underneath each of these objects, you will see a solid or dotted line interspersed with solid rectangles. These lines are known as the lifelines of that object. The idea is that the lifeline indicates a timeline for that object. So interactions that come higher in the lifeline come before things that occur lower in the lifeline. Linking these lifelines together are messages. So calculatePrice is a message that is being received and processed by an Order, getQuantity and getProduct are messages being generated by an Order and sent to an Order Line. getProduct, the dotted line from an Order Line to an Order, is a return message. getPricingDetails is a message that is going from an Order all the way to a Product, and so on. You will see different kinds of messages. I already pointed out the return message. You will also see a message known as a self-call or self-message. An example of this is calculateBasePrice that an Order is making on itself. You will also see a rectangle that goes from beginning to end on a lifeline, like on an Order. You will also see rectangles that have a beginning and an end. These are known as activations of that object. For example, when a getQuantity message is sent from an Order to an Order Line, an Order Line is activated, does something, then goes back to sleep. When a getProduct message is later received, it wakes up again and processes that message.
Reference: UML Distilled, Martin Fowler: Safari
10/25/2011
UML

10. Collaboration (Communication) Diagram
A dual of a sequence diagram is known as a collaboration diagram. Here, you don’t see objects lining up over the top with lifelines showing the timelines of interactions. Here you see the objects placed spatially and the message going across arrows that connect one object to another with the sequencing shown as numbers. For example, in this collaboration diagram, the message calculatePrice has sequence number 1, so that’s the first message. It generates two messages, getQuantity and getProduct; we know this because they are numbered 1.1 and 1.2. The third message is getPricingDetails because it is numbered 1.3, followed by two other messages, calculateBasePrice and calculateDiscounts, numbered 1.4 and 1.5. calculateDiscounts generates a message numbered 1.5.1, which is getDiscountInfo. The point to be made here contains identical information to a sequence diagram; in fact, you can convert from sequence diagrams to collaboration diagrams mechanically. It’s just a different way of showing the interactions between objects.
Reference: UML Distilled, Martin Fowler: Safari
10/25/2011
UML

11. State Diagram Reference: UML Distilled, Martin Fowler: Safari
This diagram, known as a state diagram, is another diagram that can be used to capture the dynamic behavior of a system. In this case, it is trying to capture the dynamic behavior within a particular entity. It is not talking about dynamic behavior in terms of interactions between entities, such as objects. This entity must be representable as a state machine. In this example, it is trying to capture the behavior of the user interface of a system. This user interface can be represented as a state machine. The three states are when it is showing the update hardware window, when it is searching, and the third state is when it is displaying the new hardware window. The diagram is showing how the transitions between the three states take place in the user interface.
Reference: UML Distilled, Martin Fowler: Safari
10/25/2011
UML

12. Activity Diagram Reference: UML Distilled, Martin Fowler: Safari
Activity diagrams are typically used for process modeling, such as for modeling the logic captured by an entire use case or set of use cases, or for modeling the detailed logic of a business rule. 
It is typically not used to model the behavior of a single method or single object. It is usually used for modeling higher level things like processes. You might think of this as a flowchart, but a flowchart that is not often used to show the algorithm of a typical piece of code, though it may be used for that.
Reference: UML Distilled, Martin Fowler: Safari
10/25/2011
UML

13. Advanced UML Static Operations Aggregation
So now let’s look at a couple of diagrams that are used to model more specifics within a system.
In an earlier diagram, you would have seen operations being listed within a class. At that time, we hadn’t worried about things like parameters, types of parameters, whether the operation is a static operation, or an object-level operation. In this particular case, you see an example of an operation that is declared at a class scope. getNumber is instance-scoped and getNextNewNumber, because it is underlined, is considered a static operation.
You also have seen associations between diagrams. In those previous diagrams, the specifics of those associations were not specified. There are two other associations that refine the relationship between two classes. The first is an aggregation relationship. For example, if you have a club and people who are members of the club, the relationship is stronger than just a general association because a club contains the members. This can be modeled using an aggregation relationship. You can see the notation – an open diamond at the left and an arrow at the right – that shows that the club contains the objects of the Person class.
An even stronger relationship than aggregation is composition. You have the similar membership kind of relationship, but the member object cannot exist outside of the containing object. In this case, you have an object called a Polygon that contains Points. These Points cannot exist outside of the Polygon. Similarly, you have a Circle with a Point at the center. The composition relationship says that without the Circle being there, the Point that is the center cannot be there.
Composition (cannot exist outside of)
Reference: UML Distilled, Martin Fowler: Safari
10/25/2011
UML

14. Interfaces Reference: UML Distilled, Martin Fowler: Safari
Here is another advanced UML notation: the interface. You saw class diagrams earlier. Here are those same class diagrams, extended to show interfaces.
Reference: UML Distilled, Martin Fowler: Safari
10/25/2011
UML

15. Interaction Overview Diagrams
Interaction overview diagrams are variants on UML activity diagrams which show an overview control flow. The nodes within the diagram are frames instead of the normal activities which you would see on an activity diagram, but are called frames. There are two types of frame shown: interaction frames which depict any type of UML interaction diagram (sequence diagram, communication diagram, timing diagram, interaction overview diagram) or interaction occurrence frames which indicate an activity or operation to invoke.
Reference: UML Distilled, Martin Fowler: Safari
10/25/2011
UML

16. Swimlanes Reference: UML Distilled, Martin Fowler: Safari
This slide illustrates a UML notation known as swimlanes. This is nothing more than an activity diagram, but it has been partitioned into these parallel components known as swimlanes, where the activities performed by a particular actor all fall within one swimlane. So the Stakeholder actor does the Prioritize Enterprise Requirements and Describe Enterprise Requirements activities within one swimlane, the Requirements Analyst does the Model Enterprise Requirements activity within a swimlane, and the Enterprise Architecture does the Model Enterprise Business Architecture, Support Project Teams, and Model Enterprise Technical Architecture activities within a swimlane.
Once again, this is nothing more than a regular activity diagram, except that it has been partitioned into swimlanes that show which of the actors are doing which activities.
Reference: UML Distilled, Martin Fowler: Safari
10/25/2011
UML

17. Package Diagram (Package == Namespace)
A package diagram depicts the dependencies between the pieces (each piece being a package) that make up a model.
Package diagrams can use packages containing use cases to illustrate the functionality of a software system broken up into subsystems.
Package diagrams can use packages that represent the different layers of a software system to illustrate the layered architecture of a software system. Packages are just ways to collect other artifacts into components that meet a single perpose. The dependencies between these packages can be adorned with labels / stereotypes to indicate the communication mechanism between the layers.
Reference: UML Distilled, Martin Fowler: Safari
10/25/2011
UML

18. Deployment Diagram Reference: UML Distilled, Martin Fowler: Safari
The deployment diagram shows how a system will be physically deployed in the hardware environment. Its purpose is to show where the different components of the system will physically run and how they will communicate with each other.
(Ref:
Reference: UML Distilled, Martin Fowler: Safari
10/25/2011
UML

19. Thank you!
10/25/2011
UML