From Wiki
Jump to navigationJump to search


  • A family of visual languages to describe systems (not necessarily but usually software systems).
  • A UML is a modeling language and not a method. A method = modeling language + process.
    • A modeling language is a graphical notation that methods use to express design.
    • The process is the methods advice on what steps to take in doing a design.
    • The modeling language is the most important part of the method - key for communication as it expresses design.
  • The fundamental reason to use UML is that it allows communication of concepts clearer than the alternatives (natural language and code).
    • Natural language is too imprecise and code is too detailed. UML is a middle ground - has precision and can be used to highlight important details.
  • UML is not a research project - it is a collection of practices gained through industry usage.
  • A system can be viewed through different perspectives. E.g. a house can be viewed differently by the landlord, tenant, plumber, architect, tax officials view.
  • In UML, different kind of diagrams allow us to have views about the system in different ways.
    • e.g. use case diagram represent system functions from the user perspective, sequence diagram is representation of objects and their temporal interactions etc.

Class Diagrams

  • A class is an intentional description ( a blueprint) of set of objects.
  • A description can be thought of as : 1) a specification and 2) a realization. In UML practice, these are usually combined.
  • Class diagrams represent a set of classes, interfaces, collaborations and their relationships.
  • They offer a static conceptual view of the system. Each class must be a concept in the users mind, rather than diagrams of pieces of data.
  • Dont make a class model a data model, class models should be responsibility oriented rather than data oriented.
  • Class diagrams can offer three perspectives:
    • Conceptual - represents the concepts in the domain.
    • Specification - represents the interfaces of the software not the implementation.
    • Implementation - represents the classes in the actual implementation.

Relations between classes


  • Represents a connection between instances of the classes. (not between the classes themselves). By default an association is bidirectional.
  • As in a representation of the references to other instances that an instance has.
  • A role can be attached to each end of an association. The role also has a multiplicity. Make sure both of these are represented.
  • For e.g. a Manager and an Employee's association role can be "manager" with multiplicity of 1 on the Manager end (each Employee has 1 manager) can and 1..* (each manager has 1 or more employees) on the Employee end.
  • C1 --- (m..n) C2 : Means that each object of class C1 is related to at least m and at most n objects of class C2. Default multiplicity is "1..1"
  • Multiplicity specifications can be on both sides.
  • Students must apply somewhere and may not apply to more than 5 colleges. No college takes more than 20,000 applications.

UML Multiplicity.PNG

  • Navigability: A direction can be imposed on an association. This means that the destination object will have a direct reference from the source object, but not the other way around.
  • for e.g. a User object can have references to Password objects, but not the other way around, since it will be a security risk.

Association Class

  • Association class allows the addition of attributes and operations to associations.
  • There can be only one instance of the association class between any two participating objects.
  • See below example, there can be only one Competency for each combination of Person and Skill.



  • Represents asymmetric bidirectional semantic connections.
  • Represents a stronger coupling between classes. for e.g. a company is made up of a number of departments.
  • Generally for relations as whole and part, master and slave, composed and composing.
  • Notation : a white diamond at the aggregation point. for e.g the white diamond will be at the end of the company.


  • Represents a stronger form of aggregation.
  • Maximum multiplicity of 1 on the aggregate side : An object may be part of only 1 composite at a time, whereas it can be part of more than 1 aggregate.
  • Automatic propagation of destruction. If a composite is destroyed, so will be its parts.
  • For e.g. a relation between a Engine and Pistons. If the engine is destroyed, so are the pistons.
  • Represented by a filled in diamond at the end of the aggregation.


  • Represents an IS-A relationship.
  • Is subject to different interpretations models.
    • Conceptual - a subtype is a kind of a supertype.
    • Specification - the interface of the subtype conforms to the interface of the supertype.
    • Implementation - Normally associated with inheritance in programming languages - but need not be. Subtyping can also be implemented through delegation.
  • Two kinds of inheritance
    • Inheritance of pre-defined functionality.
      • This is implementation inheritance. UML specialisation.
      • Often a class will specialise a superclass, which is what the subclass is.
      • Definition: Implementation inheritance represents services, attributes or operations that are declared and defined for all instances of a class, be they simple instances of the class or of any of its subclasses
    • Signing up to a contract. This is interface inheritance. UML Realisation.
      • Subclass will realize a number of interfaces - how it can behave in a number of situations.
      • Definition: Interface inheritance is used to represent those services that are declared as being required to be implemented by all concrete inheriting classes.


  • A weaker relationship than association. A dependency exists between two defined elements if a change to the definition of one may result in a change to the other.
  • Indicated by a dashed line pointing from the dependent (or client) to the independent (or supplier) element.
  • Often taken to mean “appears in the signature of some operation or attribute”.


  • Attributes are very similar to associations, e.g. Persons have names.
  • From a conceptual point, there is no difference, it is just another kind of notation.
  • From a specification and implementation level, there is a difference. Attributes imply navigability from the type to the attribute only. e.g. Student has a Roll Number.
  • Also implied that type contains its own copy of the attribute which has a value, rather than a reference (as in the case of associations).


  • Operations are the processes that a class knows how to carry out.
  • At a specification level, operations corresponds to public methods on a type.

Difference between an operation and a method

  • The difference is the name of the invocation and the response.
  • An operation is the procedure call on an object, and the method is the body of the procedure.
  • Difference exists because of run time binding and polymorphic behaviour.
  • Consider a supertype with two subtypes each overriding supertypes foo operation - then we have one operation and three methods that implement it.


  • Used for model structuring - way to group classes.
  • Corresponds to a Java Package.


  • A stereotype extends the UML Vocabulary - it is the core extension mechanism of the UML.
  • Definition: A stereotype is a new model element that extends the metamodel semantics of an existing element. They must be based on types or classes existing in the metamodel.
  • Enables us to create new kinds of basic elements deriving from existing elements in the UML Metamodel.
  • An example is the interface. Since it's a special kind of class, it is defined as a stereotype of the class.
  • Stereotypes are shown in text between guillemets, e.g. <<interface>>
  • Stereotypes can be thought of as subtypes of the meta-model types Class, Association and Generalization.


  • Useful for comments. Belongs to the view, not the model.
  • Since a note doesnt belong to the model, it can be stereotyped as a constraint.


  • A conditional relationship between model elements.
  • Expressed in OCL or in natural language.
  • TODO: Add a meaningful example.

Object Diagrams

  • Represent run-time system behaviour.
  • Use object diagrams.
  • An object diagram is like a class diagram, except it is named differently. e.g. ObjName:Class
  • Represents the structure of objects at run time, since object behaviour is dynamic, this is effectively a snapshot.
  • Also represent the links between the objects.
  • The links are instances of the class associations.
  • An object diagram is an instance of a class diagram.

Interaction Diagrams: Are models that describe how groups of objects collaborate. Typically, they capture the behaviour of a single use case.

Communication Diagrams

Communication diagrams represent an interaction: a set of objects and their relationships, including the messages they can send to each other.

Sequence Diagram

  • focus on the chronological ordering of messages.
  • It is a temporal vision of an interaction : It is for a particular interaction or a scenario.
  • Often used to represent a use case scenario.
  • A filled in arrow represents a synchronous call.
  • A blank arrow (or an half arrow) represents a asynchronous call.
  • Each message between objects is labeled with the message name and optionally the arguments and control information.
  • Control information:
    • Condition: which indicates when a message is sent (for e.g. [hasBalance]). Message will be only sent when hasBalance is true.
    • Iteration Marker: "*" a message is sent many times to multiple receiver objects, e.g. when iterating over a collection. e.g. *process() for a collection of Job objects.

Collaboration Diagram

  • Focus on the structural organization of the elements sending the messages.
  • Represents a collaboration between roles. Focuses on the structure, not that much on the time.
  • Time ordering can be shown by numbering notations.
  • Sequence and Collaboration diagrams are interchangeable - they can be transformed into one another.


  • State diagrams describe all the possible states that a particular object can get into and how the object's state changes as a result of events that reach the object.
  • The syntax for a transition label has 3 parts: Event [Guard] / Action.

Activity Diagrams

  • Activity Diagram:Describes the sequencing of activities withing the system for both conditional and parallel behaviour.
  • Special kind of statechart : where most, if not all, the states are activity states.
  • Important in system function mode ling - focusing on control flow in objects.
  • The fork - join concept is important. Fork can be used to represent concurrent activities.

Component Diagrams

  • A component is a set of classes, interfaces or collaborations. A component can represent a package, source files, DLL's, binaries etc.
  • A component diagram represents the organization and dependencies between the components. Shows the various components in a system and their dependencies.
  • A component may be split up into multiple interfaces.
  • The dependencies are between interfaces.
  • Example:

Deployment Diagrams

  • Deployment diagrams shows the physical relationships among software and hardware components in the delivered system.
  • Each node on a deployment diagram respresents some kind of computational unit.
  • A node generally consists of one or more components.

Use Case Models