Please note that you must enable JavaScript if you want larger
<code>
blocks to be highlighted. Component Notation. A component in UML is shown in the following figure with a name inside. Additional elements can be added wherever required. Component is used to represent any part of a system for which UML diagrams are made. A node in UML is represented by a square box as shown in the following figure with a name. Every once in awhile, I have to draw a UML diagram. I rarely do serious designs with UML, however sometimes I do need to depict some piece of code in a diagram and UML seems to be the best notation around. Unfortunately, various sources of information on UML tend to over-complicate things. I am not software architect and drawing UMLs is not my job. My favourite UML 'cheat sheet' is UML Distilled, by Martin Fowler. It's the only one of his books that I've read that I do recommend. Improve this answer. Follow edited Dec 2 '15 at 1:33. 12k 18 18 gold badges 84 84 silver badges 161 161 bronze badges.
The Unified Modeling Language (UML) includes interaction diagrams with the purpose to illustrate how objects interact via messages. Interaction diagrams are used for dynamic object modelling. There are two common types: sequence and communication diagrams. Communication diagrams illustrate the interactions between objects in terms of sequenced messages. In this blogpost I will provide you with an overview of basic communication diagram notations and common patterns. You should this blogpost as a cheatsheet.
Content
Links
![Uml Notation Cheat Sheet Uml Notation Cheat Sheet](/uploads/1/1/9/8/119877554/668027007.png)
Messages
Each message between objects is represented with a message expression and small arrow indicating the direction of the message. The best practise is to not number the starting message. However, even though it is legal to do, it simplifies the overall numbering if you do not do it.Messages to itself
A message from an object to itself is illustrated by a link to itself, with messages flowing among the link.Creation of instances
The UML convention is to use a message named `create` to create an instance. It is legal to use another message name. If you do use another message name, you can—and should—annotate the message with a UML stereotype, in this case `«create»`. Furthermore, you may optionally add the UML tagged value `{new}` to the lifeline box to highlight the creation.Message number sequencing
The order of messages is illustrated with sequence numbers. As stated before, the best practise is to not number the starting message, because you would create another level of number-nesting deeper than otherwise necessary.The order and nesting of subsequent messages is shown with a legal numbering scheme in which nested messages have a number appended to them. Note that you denote nesting by prepending the incoming message number to the outgoing message number.
Conditional messages
A conditional message is shown by following a sequence number with conditional clause in square brackets. The message is only sent if the clause evaluates to `true`.Mutually exclusive conditional paths
With mutually exclusive conditional paths you must modify the sequence expressions with a conditional letter. By convention, the first letter used is `a`. The figure below states that either `1a` or `1b` could execute after `msg1`. Since either could be the first internal message, both are sequence number 1.Iteration or looping
Iteration over a collection
Asynchronous calls
Asynchronous calls are shown with a stick arrow; synchronous calls with a filled arrow, see the figure below.draw.io
All of above diagrams, are created with draw.io.
References
Larman, C. (2005). Applying UML and patterns: an introduction to object-oriented analysis and design and the unified proces (3th ed.) (pp. 240-247). Upper Saddle River (New Jersey): Pearson Education, Inc.
UML has many diagrams useful for various purposes in software development which may also be useful in your project designs. For this class, the only truly 'required' UML diagram is going to be the UML Class Diagram, unless we explicitly ask you to make a certain form of UML diagram for your project.
This page just provides a brief overview; see the 'Readings' listed for each diagram type below for more information. Note that all of the Fowler references are accessible within JHUs network or with a JHED ID at UML Distilled by Fowler.
- A good quick reference for UML is Allen Holub's.
- An even more concise Cheat Sheet.
Overview
UML is a diagramming standard for diagrams to aid the design process- A picture is worth 1000 words
- A common picture language helps just like a common verbal language (English, French, etc) does.
- UML greatly facilitates object-oriented/architecture-centric design: all of the diagrams but two center on the object/component structure.
Classes of UML diagrams
- Static disagrams: no temporal component. Most show classes/objects and how they relate.
- Dynamic diagrams: Show how objects interact over time
Different Perspectives from which to use Diagrams
UML diagrams can be used at all levels of design, and their use issubtly different at each level:
- Conceptual (part of requirements capture)
- To understand the underlying domain; no need to think about the relation to the resulting software. Domain models (discussed later) are a conceptual model. Conceptual models are a good place to start design from.
- Specification (part of initial design)
- Looking at the entities in the diagrams as specifications for what the code should do (interfaces), not the actual code (implementation). Most often the perspective you want to use.
- Implementation (part of coding)
- The actual implementation.
To diagram implementations effectively you must focus on key attribs/operations or the pictures get too big.
Class diagrams
Readings: Fowler Chapters 3 and 5; HFOOA&Dpp.577,3,180-185,206-207; Ambler
Class diagrams are the most useful kind of UML diagram. Once you have understoodthe basics here are some usage suggestions.
Making Good Class Diagrams
Avoid making diagrams that have too much information in them- Leave out non-critical attributes and associations
- Make focused diagrams: for a given use-case, make a class diagram only showing the classes relevant for the use-case
- Don't show classes that are not central to the design, e.g. String, HashSet (well, at implementation level could show this), etc.
- Don't put in implementation-related notations too early (navigability, public/private, types)
Associations
- At the conceptual level they are just the abstract association;
- at the specification level they imply responsibilities to change one another;
- at the implementation level they imply pointers for navigability.
- They represent a permanent relation; use arity 0..1 to indicate it may come and go.
Naming roles
- Only roles that have an important name for them need explicit names
- If there is no name on an end, the class name at that end is in effect the implicit name for the role.
Attributes
- They duplicate associations to some degree: Customer has an order list so it probably has an attribute orderList.
- Generally for simplicity if there is a named association shown there is no need to show the attribute in the class
Interfaces
- Interfaces are diagrammed as classes with <<interface>> in the upper right corner
- The <<...>> is a stereotype: it means we are using the UML notation for something that is similar, but different, than what it was originally intended for.
- You don't generalize an interface, you realize it -- use the same arrow as generalization but make the line dashed. Note that the OOA&D book does not dash the line here.
Abstract classes
To indicate a class is abstract, add the constraint{abstract}.
Aggregation and composition
- Aggregation is a whole-part association
- In UML, a diamond is put on the 'whole' end of the whole-part
- If the diamond is filled in, it is furthermore a composition: the parts are integral components of the whole, and when the whole dies the parts die too.
- It can be difficult to distinguish aggregation from composition; don't get too tied up about it.
Use-case Diagrams
![Notation Notation](/uploads/1/1/9/8/119877554/143258518.jpg)
Readings: Fowler Chapter 9, HFOOA&D pp.296-297; Ambler
- Use-case diagrams are useful early on: they clarify who will be involved in what use-cases. See HFOOA&D pp.296-297 for a good example.
- If there are not many distinct actors involved in an application, use-case diagrams are not very helpful.
Sequence Diagrams
Readings: Fowler Ch. 4, HFOOA&D p.567; Ambler
- Sequence, object collaboration, and activity diagrams are designed to show dynamic activites, unlike static class diagrams
- Sequence diagrams are arguably the most useful of the three
- They are particularly good at the design phase for cutting through the fuzziness in use-cases: draw a sequence diagram for the use-case
Activity Diagrams
Readings: Fowler Ch. 11; Ambler
Uml Notation Cheat Sheet Worksheet
- A dynamic form of diagram
- The only form of UML diagram that isn't strongly object-based
- Designed to show activites without assigning them to objects yet
- Useful for early specification of use-cases, in requrements
Package, Component and deployment diagrams
Readings: Fowler Chapter 7,8,14; AmblerPackage; AmblerComponent;AmblerDeployment
- Package diagrams are simple variations on class diagrams to show packages and their relationships
- Component diagrams are used in large pieces of software to show the components and how they are related
- Deployment diagrams are for distributed systems to show the different nodes and how connected
- None of these diagrams are very useful for appplications with just 1-2 packages/components/deployment nodes.
Object Diagrams
Readings: Fowler Ch. 6; Ambler
These diagrams are very simple, they just show a snapshot of the object heap atruntime.
Uml Notation Cheat Sheet Grade
Communication Diagrams
Uml Cheat Sheet Pdf
Readings: Fowler Ch 12; Ambler
- Sequence diagrams are generally the best for showing object-centric interactions
- For some cases, communication diagrams also can be useful
- Communication diagrams also show the static interrelation of objects (good), but don't illustrate the temporal aspect as well as sequence diagrams (bad).
State Machine Diagrams
Readings: Fowler Ch. 10; HFOOA&D p.568-569; Ambler,Amblerstyle guide
State diagrams are just fancy finite automata: each node is adifferent state, and edges indicate dynamic transitions from state to state.
When to use state diagrams?
State structure can be an important dimension of some designs
- Consider states that classes may be in; For instance, an invoice is in one of the following states: just created: pending, scheduled, overdue, closed.
- A sign that an object has state: some messages only work some of the time (in certain states only).
- Some systems have no interesting stateful classes. Don't focus on state structure if there are only two states.
- But, recognizing them when they exist is critical, and a UML state diagram will be helpful.