[Skip Navigation] [Remove Frame] [CS320] [Text Version] uml.html Sat Dec 23 08:01:05 PST 2006
Opening the PDF files on this page may require you to download Adobe Reader or an equivalent viewer (GhostScript).


    The UML -- The Unified Modelling Language


      The Unified Modeling Language -- -- --(UML)
      UMLlogo was created by the Three_Amigos of the Rational Corporation. It is intended to be a common shared language used in medium to large scale software projects. CORBA has adopted it as a common way to diagram objects, classes, etc. The Object Management Group(OMG) issues standard and is now up to version 1.3 which links it to their metadata standard XMI -- using the XML language. Many software companies support the UML and several CASE tools use it. Rational has a particular CASE tool called Rational Rose.

      The UML has become part of the curriculum in Computer Science at CSUSB as part of the ROOT project including installing Rational Rose.

      Beginners Start Here

        Why Use the UML

        If you become familiar with a way to draw pictures of your ideas you will find that you will be able to think of more ideas and also to work out the consequences of your decisions. The UML is such a graphic language. It will probably become a popular and standardized way of analysing problems and designing solutions using objects. As a widely used standard the UML is becoming valuable in the job market.

        The UML is an important skill to survive the Computer Science degrees here.

        How to Draw Pictures of a Static Structure

        The heart of an object oriented program are the types of objects and the links between the objects. Here [ uml1.html ] are some notes on how to draw diagrams of simple C++ structures and classes. See [ uml1b.html ] for the more advanced C++ ideas (pointers, friends, inheritance for example). See [ cs320wuml.html ] to see how the UML can be used to describe the structures and semantics of programming language.

        Using Rational Rose 4.0

        It helps if you have a tool to draw the diagrams and maintain the documentation that describes the problem and its solution: [ uml3.html ]

        How to Draw Pictures of Dynamics

        The development of object-oriented software starts and ends with the study of how the system and its parts work together to help the user: [ uml2.html ]


        These notes are a very short and incomplete summary of the UML. The Rational UML Resource Pages should be consulted for definitive examples and definitions. There is a list of WWW resources below [ See Also ]

        This set of notes leaves out several parts of the UML. They do not cover the notations needed for industrial size problems:

        • How the parts of a piece of software are grouped into logical packages. [ uml.gen.gif ]
        • How the design is packaged into pieces of code(Component Diagrams). [ modules.gif ]
        • How the software is distributed over the available hardware(Deployment Diagrams). [ deployment.gif ]
        • How a complex business procedure is represented (Activity Diagrams)

      . . . . . . . . . ( end of section Beginners Start Here) <<Contents | End>>

      Advanced Ideas

      See [ uml4.html ] for notes on polymorphism, patterns and processes. See the Object Constraint Language [ ocl.html ] to find out how to document the properties of things shown in diagrams.

      Quick Reference

      Here is a quick list of diagram types in the UML with links to graphic images that are examples of that diagram.
      1. General Purpose Concepts
      2. Use-Case Diagram
      3. Class Diagram [ uml.coll0.gif ] [ uml.coll1.jpg ] [ uml4.jpg ]
      4. State-Transition Diagrams [ uml2.html ]
      5. Interaction Diagrams [ uml2.html ]
      6. Component Diagrams
      7. Deployment Diagrams

      See Also

      My glossary: [ uml.glossary.html ]

      (OCL): Object Constraint Language [ ocl.html ]

    1. ROOT::= See http://cse.csusb.edu/rootproj/, This project incorporated object-oriented technology into the core of the BS degee in computer Science at CSUSB.


      1. CS201::= See http://cse.csusb.edu/dick/cs201.
      2. CS202::= See http://cse.csusb.edu/dick/cs202.
      3. CS320::= See http://cse.csusb.edu/dick/cs320, [ cs320wuml.html ]
      4. CS330::= See http://cse.csusb.edu/cs330.

    2. CORBA::="Common Object Request Broker Association" [ CORBA in se ] a consortium of companies working to make object technology accessible accross many platforms and types of systems.

    3. XMI::= See http://cse.csusb.edu/dick/samples/uml.glossary.html#XMI

    4. XML::=eXtensible Markup Language, [ xml.html ]

      Complete and up to date information can be found on the Internet by following the World Wide Web links below. The UML is defined and maintained by the Three_Amigos at Rational Corporation's Web site.

    5. Rational::= See http://www.rational.com/

      Online Tutorials: [ http://yukon.genie.uottawa.ca/~lavoie/software/uml/ ]

      [ http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/rose/ ] (Actually uses Booch not UML)

      • (introbook): UML Distilled: Applying the Standard Object Modeling Language by: Martin Fowler, Kendall Scott part of the Object Technology Series ISBN: 0-201-32563-2 (Search under [ catalogtitle.qry ] )
      • (refbook): UML in a Nutshell (the Cat book) by Sinan Si Alhir, O'Reilly 1998

      UML Glossary

        UML stands for the Unified Modelling Language

        Note. In this glossary a definition is written like this

        When there are several alternative meanings they are separated by a vertical bar symbol: "|" read as "or". This is an informal extension of the notation John Backus and Pete Naur developed in 1960. [ BNF in glossary ] [ BNF in comp.text.Meta ] and
      1. Algol60::= See http://csci.csusb.edu/dick/samples/algol60.syntax.html

        A B

      2. AKO::="A Kind Of" -- object-oriented jargon for relation between general and particular.
      3. APO::="A Part Of" -- object-oriented jargon for relations between pats and wholes, compare with AKO.

      4. abstract::stereotype=indicates that a class defines an abstraction so that no objects of this type exist except as objects of the specialized subtypes of this type. You can have pointers or references to abstract classes but you can not have any objects or variables of an abstract type. The pointers always refer to objects in a more specific concrete classes. [ uml.shape.gif ] [ uml.find.gif ]
      5. abstract_data_type::=a collection of data with invisible attributes (the data) that is manipulated only by operations and so hides its attributes behind an interface.
      6. abstraction::=indicates that something is left out of a description or definition.

      7. actor::=an entity that starts scenarios and gets results from them. An actor has an iconic stick-figure form but is actually a class or type with the <<actor>> sterotype. [ uml.usecases.gif ]
      8. actors::=plural of actor.

      9. actual_parameter::=a value supplied when generating a particular version of a parameterized class or package. Actual parameters are listed inside diamond brackets like this <for,example>.

      10. aggregation::=a way that one class can refer to another class without having possession of it + a weak form of 'has-a' / APO link + if the whole object is an aggregation then deleting it does not effect the existence of the aggregated part. This relationship is shown by an open diamond at one end of a link. The other end may have an arrow head indicating the link can be navigated in one direction only.

      11. application_domain::noun=a collection of more or less similar solutions.

      12. association::=A kind of relationship or link between classes. Associations are further documented by stereotypes + roles + multiplicities + constraints + descriptive names + aggregation indicators + navigability indicators. [ uml.coll0.gif ] [ uml.coll1.jpg ] [ uml.game.gif ] [ uml.association.gif ] [ uml.link.gif ]

      13. attributes::=plural of attribute.
      14. attribute::=a named value that an object or class is responsible for maintaining. [ uml1.gif ]


      15. class::=a part of a UML class_diagram indicating a collection of objects with similar responsibilities and/or behaviors. It can be shown as a box with a name in it or as a box with a name, attributes and operations. [ uml1.gif ] [ uml3.gif ] [ uml.game.gif ] [ clock1.gif ] [ clock2.gif ]

      16. classes::=plural of class.

      17. class_diagram::=a diagram showing classes and the associations between them. [ uml3.gif ] [ uml.coll0.gif ] [ uml.coll1.jpg ] [ uml4.jpg ]

      18. class_utility::=A class with only static attributes and static functions, -- for example a math library. [ umlutility.gif ] [ umlutility.mdl ]

        collaboration_diagram=a description of the collaborations between objects as they fulfil a usecase. [ uml.collab.gif ]

      19. collaboration::=an interaction between one object or class with another object or class. Typically the first object or class invokes an operation of the other or accesses an attribute.
      20. collaborations::=plural of collaboration.

      21. communicating::=the process of sending and receiving data through a communication_association linking an actor and an usecase.
      22. communication_association::an association or link in a usecase_diagram connecting an actor to a usecase. [ uml.usecases.gif ]

      23. composition::= a strong form of the 'has_a' or APO relation so that deleting the whole automatically removes the parts as well. Composition fits when objects of one class are made up of parts that are objects of of other classes, for example when they are implemented using fields in structures, items in records, columns in a data base, or pieces of a document. However, in some cases, the responsibility for keeping an object alive changes during that objects life, and so that objects class would be shown as being parts of several different compositions. [ clock2.gif ] [ uml.period.gif ] [ uml.link.gif ]

      24. concrete::=the opposite of abstract - a concrete class is defined in enough detail so that objects can be constructed for it.

      25. constraint::=A logical formula or informal text stating something that must be true and written inside curly braces | one of a small number of words indicating a logical constraint - for example "complete" or frozen. [ uml.gen.gif ] [ uml.dynamic.gif ]
      26. constraints::=plural of constraint.

      27. constructor::stereotype=indicates that an operation creates a new object of its class. Notes. In UML the initial values of attributes can be indicated in the specification of a class and so constructors are optional. In many OO language like C++ and Java default attribute values are not permitted and so constructors are effectively mandatory. Also notice that a constructor should not be shown as returning any type of object.

        D E

      28. destructor::stereotype=indicates that an operator deletes an object of its class. Note a destructor is a C++ idea where its name is always the name of the class prefixed with a tilde symbol.

      29. dependencies::=plural of dependency.
      30. dependency::=a relationship between parts of an UML model drawn as a dashed line with an arrow head that indicates that if one thing changes then the change may effect the other thing. Often one thing uses the other thing(usage). [ uml.gen.gif ] [ usage.gif ]

      31. domain::= problem_domain | application_domain.

      32. dynamic::stereotype=a generalization can be described as dynamic if it possible for an object to change its classification during its life. This is the opposite of the normal static form of generalization. Also see frozen. [ uml.dynamic.gif ]

      33. end::=each association has 2 ends and associated with each end is ( a class, a role the association plays in the class at the other end, a multiplicity).

        F G H

      34. formal_parameter::=a parameter that is used in a parameterized definition in place of an actual_parameter that can be supplied later.

      35. frozen::=a property of an end of an association that no links are (added|deleted|moved) from an object at the frozen end.

      36. generalization::=relationship (is_a ) between a specialized class and a more general class where objects of the more specialized class ( the subtype) are automatically also instances of the more general type. It is typically easier to implement static generalizations in C++ by using inheritance than to implement dynamic forms. Dynamic generalizations need patterns developed by the GoF [ uml.gif ] [ uml.gen2.gif ] [ uml.gender.gif ] [ uml.shape.gif ] [ uml.dynamic.gif ]

        I J K

      37. icon::= a symbol that appears on a computer screen that may manipulated using a mous or other pointing device.
      38. icons::=plural of icon.

      39. interface::stereotype=indicates a set of operations that may be defined by one or more classes and used by one or more classes. An interface is an abstraction with no implementation and no attributes. [ uml.interface.gif ] [ uml.client.gif ]
      40. interfaces::=plural of interface.

      41. key::=an attribute or set of attributes of a class that uniquely identify a particular instance of the class.

        L M

      42. link::=a line connecting two boxes or other icons.

      43. MOF::="Meta Object Facility", CORBA interface describing a UML model, also see XMI.

      44. multiplicities::=plural of multiplicity.
      45. multiplicity::=numbers or sets of numbers (using a comma or range) placed at an end of an association indicating how many object of the closest type correspond thru the link to a single item at the other end. If omittedd it means: an unknown number of. [ uml.period.gif ] [ uml.game.gif ] [ uml.coll1.jpg ] Note. Links that have many-to-one multiplicities are nearly always simpler to implement and easier to understand than those with muliplicities other than one at both ends.

        N O

      46. navigable::=an association that can be navigated in both directions. Note. if an association is not navigable it is simpler to implement it because storing an identifier of an object allows it to be found.
      47. navigate::verb=to gain access to a object by following an association linking one object to the other.
      48. navigated::=past participle of navigate..

      49. note::=an informal remark linked to a part of a UML diagram. The link is a dotted line and the remark is in a rectangular box with the corner folded over. Looks a little like a stereotype and a constraint. [ uml.gen.gif ]

      50. objects::=plural of object.
      51. object::=following
        1. In analysis, an object is an instance of a class in the problem_domain.
        2. In design, an object is something with an unique identity that encapsulates some know-how (operations) and some values(attibutes).
        3. In code, an object is a piece of storage plus some sub-programs that have privileged access to that storage. [ object in glossary ]

      52. operations::=things that an object in a class knows how to do, in UML these are placed in the lowest compartment in a three compartment box. [ uml1.gif ]

        P Q

      53. package::=an icon in UML that looks like a folder and refers to another UML diagram that either exists or may be in the process of creation. A package replace a collection of things by a single thing. [ uml.gen.gif ]
      54. packages::=plural of package.

      55. parameter::=actual_parameter | formal_parameter, In mathematics this is a "constant variable".
      56. parameterized::=a class or package in UML can be given a parameter and then for each possible value of the parameters a special version of the class or package is generated. Compare with an Ada generic and a C++ template. [ uml.template.gif ] [ uml.find.gif ]

      57. patterns::= See http://cse.csusb.edu/dick/se.html#Patterns.
      58. pattern::patterns=a recurring problem which involves compromising between several forces and which has a preffered and documented solution. See GoF.

      59. pointer::=a technique for implementing aggregation and linked data structures where an attribute of one object stores the physical address of the other object. Compare key and see navigable. [ uml.link.gif ]

      60. problem_domain::=a collection of more or less similar problems selected for practical or theoretical reasons.

        R S

      61. result::=the end point of a scenario.
      62. results::=the end points of a set of scenarios.

      63. roles::=plural of role.
      64. role::=a word or phrase written where a link meets an box indicating the part played by the class in the relationship indicated by the link. See rolename. For example a link from Adult to Child indicating parenthood might have parent at the Adult end and child at the other. When the role is the same as the class but with lower case initial letters it can be left out.
      65. rolename::=A name string near the end of the link indicating the role played by the class in the association attached to end of the path near the rolename.

      66. scenario::=A description of how a particular actor achieves a tangible result.
      67. scenarios::=plural of scenario.

      68. sequence::diagram=a diagram showing the sequence of messages passed between objects to achieve a given usecase. [ uml.seq.gif ]

      69. state::=a particular set of values for the attributes of an object.
      70. statechart::diagram=a way of documenting the states of an object and the changes that can occur to it during its life.
      71. state_diagram::=statechart. [ uml.states.gif ]

      72. static::=something that is permanent and can't change. In UML generalizations are normally static but there is a stereotype that allows a classification to change. See frozen.

      73. stereotype::UML=a special note looking like this: <<example>> that adds to the meaning of a part of a UML diagram. [ uml.gen.gif ]

      74. subtype::=One class is a subtype of another class if all the operations of the second class of object also apply to objects of the first type - perhaps in a different way. Subtypes shown by the generalization arrow that has an open arrow head.

        T U V

      75. template::= C++ jargon for the UML parameterized class. [ uml.template.gif ] [ uml.find.gif ]

      76. usage::=a special kind of dependency where one piece of a program makes use of another part of the program. [ usage.gif ]

      77. usecase::=a set of scenarios sharing a class of similar actors achieving similar tangible results that is documented by a natural language text and pictured as an oval icon. [ uml.usecases.gif ]

      78. usecase_diagram::=a UML diagram that shows one or actors communicating with one or more usecases.

      79. usecases::=plural of usecase. [ uml.usecases.gif ]

      80. utility::=See class_utility.

      81. visibility::=an indicator(plus, minus, hash) indicating whether a rolename | attribute | operation can be accessed from outside a class. Rational Rose uses some neat little icons involving keys and locks to indicate the degree of visibility of attributes, operations, and roles. [ Privacy in uml1 ] [ uml.link.gif ]

        W X Y Z

      82. XMI::=" A standard way to present MOF meta-data modeling objects using XML". //ftp.pmg.org/pub/docs/ad/98-1005.pdf

      83. XML::= See http://cse.csusb.edu/dick/samples/xml.html


      84. Three_amigos::abbreviation={ Grady Booch, Ivar Jacobsen, James Rumbaugh }. (See [ JokeUML in methods ] and [ Unified in methods ] )

      85. GoF::abbreviation=The_Gang_of_Four.
      86. The_Gang_of_Four::abbreviation={Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides}, Four OO thinkers who wrote an influential book of design patterns.

      87. OO::abbreviation=Object-Oriented.

      88. OMT::method=The Object Modelling Method developed by Rumbaugh et al that forms one of UML's parents.

      89. TBA::="To Be Announced", indicating work that needs completing.

        Parts of Speech

        In this glossary I sometimes indicate the syntactic class of a word used in English as well as UML.
      90. adjective::=qualifies a noun by adding properties to it.
      91. adverb::=qualifies a verb by adding properties to it.
      92. noun::=names something.
      93. verb::=indicates an action or relationship.


      94. tilde::= "~", indicates a destructor in C++.
      95. plus::="+", indicates public visibility for an operation or attribute.
      96. minus::="-", indicates private visibility for an operation or attribute.
      97. hash::="#", indicates protected visibility for an operation or attribute.
      98. range::="..", indicates a set of numbers lying between to values.
      99. colon::=":", used to separate a name of a parameter or attribute or operation from a class.
      100. comma::=","used to separate items in a set.

      . . . . . . . . . ( end of section UML Glossary) <<Contents | End>>

      See Also

    6. ROOT::= See http://cse.csusb.edu/rootproj/, This project incorporated object-oriented technology into the core of the BS degee in computer Science at CSUSB.

      Complete and up to date information can be found on the Internet by following the World Wide Web links below. UML is defined and maintained by the Three_Amigos at Rational Corporation's Web site.

    7. Rational::= See http://www.rational.com/

      Online Tutorials: [ http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/rose/ ] (Actually uses Booch not UML) Books:

      • UML Distilled: Applying the Standard Object Modeling Language by: Martin Fowler, Kendall Scott part of the Object Technology Series ISBN: 0-201-32563-2 (Search under [ catalogtitle.qry ] )

    . . . . . . . . . ( end of section UML) <<Contents | End>>