UML Diagrams Ian Holyer UML slide What is UML

Document Sample
UML Diagrams Ian Holyer UML slide What is UML Powered By Docstoc
					UML Diagrams

   Ian Holyer




   UML, slide 1
                What is UML?
• UML = Unified Modelling Language
• For modelling software systems
   – in an Object Oriented style
   – independent of actual programming language
• Merges previous approaches of Booch, Rumbaugh,
  Jacobson (the "Three Amigos")
• Has become the primary standard (of the OMG =
  Object Management Group)
• See Wikipedia entry and type UML 2 into Google to
  find references & tutorials

                      UML, slide 2
              What is UML for?
• It is a standard for drawing diagrams
• The diagrams illustrate development documents,
  helping to communicate ideas
• It does not replace the text, just enhances it
• It can be used as part of any development
  methodology, including agile ones:
   – UP = Unified Process, developed specifically to go
      alongside UML, using it with sophisticated tools
      which allow "round trip engineering"
   – XP = Extreme Programming, using it as the standard
      choice for drawing explanatory diagrams
                      UML, slide 3
      What diagrams are supported?
• UML supports 13 types of diagram, but the most
  important ones are:
   – use case diagram (for analysis)
   – class diagram (for design)
   – sequence diagram or activity diagram or state
     machine diagram (was called state chart) (for
     implementation)
• The others are
   – component, composite structure, deployment,
     object, package, communication (was called
     collaboration) interaction overview, timing

                       UML, slide 4
         What style does UML use?
• UML defines plain, simple line-drawings
• The idea is that they should be capable of being drawn
  with any available drawing tool, or scribbled freehand
• The diagrams describe entities and relationships
   – boxes are used for entities
   – lines joining them are used for relationships
   – labels add detail to boxes and lines
• You can colour in the boxes (or even replace them with
  images) if you keep them recognisable, and only a few
  colours with contrasting greyscales for the colour-blind

                       UML, slide 5
            Should you use UML?
• UML diagrams illustrate what you are saying, so if
  what you say doesn't need illustrating, don't use it
• The advice about having diagrams in a report is
   – they can help the reader to understand quickly
   – they provide variety, breaking up turgid text
   – they should contain info proportional to their space
• The rule about UML is:
   – if you have a diagram
   – and it is about modelling
   – then you should use UML for it
                        UML, slide 6
 What should a UML diagram contain?
• A mistake people sometimes make is to think they
  have to produce an illustration which is a complete
  class diagram (say) describing their whole system
• Even if you have a complete diagram, you only want
  a small extract from it in each illustration, to go with
  what you are saying at that moment
• You may not have a complete diagram, just a few
  illustrations, or the complete diagram may appear
  split over a number of illustrations, or it may appear
  as a whole in an appendix or separate document



                        UML, slide 7
        Which UML tool do I use?
• If you just want to draw the simplest diagrams, use
  something small and simple like UMLet
• If you want to try something more sophisticated, use
  Poseidon (community edition, or department license)
• There are many more possibilities, so if you want
  something else, try typing UML drawing tool survey
  into Google




                       UML, slide 8
                 Use case diagrams
• Use case diagrams are used for overviews in analysis
• They show what kinds of user the system is going to
  have, and what kinds of things they will want to do




                                      Visit web site


       Visitor




                       UML, slide 9
                         Actors
•   An actor is a "user" outside the system
•   It doesn't have to be a person
•   It is drawn with a stick figure shape
•   It is just another box, but with an unusual look
•   A label underneath gives it a name




                           Visitor

                         UML, slide 10
               Thinking of Actors
• A use case diagram can help make sure you have
  thought of all the possible users


 Member of Department


                                        Visit web site

   Member of Public




    Search Engine
                        UML, slide 11
                      Use Cases
•   A use case is something the system is supposed to do
•   It is a global operation of the system
•   It is from an outside users point of view
•   It is drawn as an ellipse, but it is just another box
•   A label in the middle gives it a name



                        Visit web site




                         UML, slide 12
       Thinking of all the Use Cases
• A use case diagram helps to make sure you have
  thought of all the uses which your system can be put to


                                        Visit normal page



                                       Visit protected page


      Visitor
                                       Create or edit page



                       UML, slide 13
                  Relationships
• The standard relationship between an actor and a use
  case is that the actor is involved in the use case
• It is shown as a simple straight line joining the boxes




                                        Visit web site


       Visitor



                        UML, slide 14
                    Generalisation
• Another standard relationship is the generalisation
  relationship between two actors
• This is the same sort of relationship as inheritance
  between two Java classes
• It is drawn as a line with a hollow arrowhead
• The arrow points in the Java "extends" direction




          Student           Member of Department

                       UML, slide 15
          Making Diagrams Simpler
• Generalisation between actors may seem strange since
  they are not going to be implemented!
• It can make explanations clearer, and diagrams simpler

                                        View course info

 Member of Department
                                        View personal data


                                        Register on a unit

       Student
                        UML, slide 16
            Generalised use cases
• One use case can be a generalization of another


                      Visit web page




                  Visit protected web page



                        UML, slide 17
                         Inclusion
• Another common relationship is inclusion


                          authenticate
  Visit protected page                    Check password


                           «include»
  Visit protected page                    Check password


                         <<include>>
  Visit protected page                    Check password



                          UML, slide 18
                      Labels
• A label can be a decoration like an arrow head, which
  can be conventional or can have any meaning you want
• It can be a unique name
                      authenticate

• It can be a "note" surrounded by European quote marks
  (officially called a "stereotype" in UML) and less-than
  and greater-than signs will do instead of quotes
                       «include»

                      <<include>>


                       UML, slide 19
 How do you use Use Case Diagrams?
• There are other features, but you can look them up
• The diagrams are deliberately simple, free of jargon or
  technical detail, and suitable for clients or users
• Use cases just name the things you are talking about
• To use them in analysis documents, the actual
  requirements or specifications go in the text
• The purpose of diagrams is to illustrate, so you are in
  control, & each diagram in a report shows just the part
  of the system you want to talk about at that moment
• A sophisticated tool holds a complete "diagram" for
  the whole system, then extracts and prints views

                       UML, slide 20
                   Class Diagrams
•   They show the object oriented structure of a program
•   They describe the static division into units/components
•   They may lead to actual classes (modules)
•   They show the name, fields and methods of a class, &
    relationships with other classes via references or calls

                         Vehicle
                      make: String
                      wheels: int
                      draw(): void
                      move(): void

                         UML, slide 21
                 Abbreviations
• In one diagram, you only have to show those classes
  you are talking about at the moment
• And you only have to show the fields or methods you
  are interested in at the moment
• You can leave out some or all fields, and some or all
  methods
• If you leave out all fields but show some methods, use
  a thin blank field box
     Vehicle          Vehicle            Vehicle
                   make: String        draw(): void
                   wheels: int         move(): void

                       UML, slide 22
                     Superclasses
• An empty-headed arrow goes from a class to a
  superclass, representing Java's extends or implements
• The superclass has an italic name if it is an interface or
  abstract class, i.e. if it has no objects


            Animal                       Cat



             Cat                        Kitten



                        UML, slide 23
               Class Relationships
• A relationship in a class diagram is shown as a line
• The line can have a label in the middle, or at each end,
  and the ends can be decorated with arrow symbols,
  some of which have standard meanings and some not
                     attached to         has
      Vehicle                                    Wheel
                     1                   2..*

                         associated with
        Unit                                    Student
                     *                     *

• A filled diamond indicates ownership, an open
  diamond indicates non-owned parts
                         UML, slide 24